Core Web Vitals per siti PHP: come risolvere LCP, INP e CLS

Core Web Vitals per i siti PHP non sono un argomento esclusivamente front-end. Una pagina PHP lenta può impiegare un secondo solo per produrre HTML e nessuna quantità di ottimizzazione dell'immagine lo recupera. Allo stesso tempo, un server molto veloce non aiuta se un'immagine hero da 1,5 MB blocca il paint più grande. Ecco come affrontiamo entrambe le parti sui nostri siti PHP (integrono.com esegue PHP-FPM dietro nginx e Cloudflare) e sui progetti dei clienti.

Cosa misurano Core Web Vitals

• LCP ( Largest Contentful Paint): quando viene eseguito il rendering dell'elemento visibile più grande (solitamente un'immagine hero o un blocco di intestazione). Buono è 2,5 secondi o meno.
• INP ( Interaction to Next Paint): la velocità con cui la pagina risponde visivamente dopo clic, tocchi e pressioni di tasti, durante l'intera visita. Buono è 200 ms o meno.
• CLS ( Cumulative Layout Shift): quanti contenuti saltano durante il caricamento. Buono è 0,1 o meno.

Google li valuta sui dati sul campo degli utenti reali di Chrome, al 75° percentile, separatamente per dispositivi mobili e desktop. Ciò significa che un modello lento o un paese lento possono deludere l’intero gruppo. Gli strumenti di laboratorio come Lighthouse servono per il debug, non per il punteggio finale.

Passaggio 1. Misurare nel modo giusto

1. Apri il report Core Web Vitals in Google Search Console per vedere quali gruppi di URL falliscono e su quale metrica.
2. Controlla PageSpeed Insights per un URL da ciascun gruppo in errore. Il blocco "dati del campo" in alto è ciò che conta; il blocco Lighthouse sottostante è un test di laboratorio che spiega il perché.
3. Utilizza il pannello Prestazioni in Chrome DevTools con rallentamento della CPU 4x e "4G lento" per riprodurre una tipica esperienza mobile.
4. Per un monitoraggio continuo, raccogli i dati degli utenti reali con la libreria JavaScript web-vitals e inviali alla tua analisi.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Passaggio 2. Correggere prima il tempo di risposta del server ( TTFB).

LCP include il tempo prima dell'arrivo del primo byte. Se la generazione del tuo codice HTML impiega 800 ms, hai già speso un terzo del budget. Sui siti PHP le solite leve sono:

• Abilita OPcache e assicurati che sia abbastanza grande da contenere tutti gli script. Senza di esso PHP ricompila i file ad ogni richiesta.
• Ottimizza PHP-FPM. Troppi pochi lavoratori in coda per le richieste, troppa memoria esaurita. Guarda la pagina di stato PHP-FPM per "coda di ascolto" e "numero massimo di bambini raggiunto".
• Memorizza nella cache intere pagine per visitatori anonimi (nginx fastcgi_cache, una cache di risposta Laravel o regole della cache Cloudflare) e memorizza nella cache frammenti o risultati di query con Redis.
• Correggi le query lente. Attiva il registro delle query lente, cerca modelli N+1 e aggiungi indici. Una pagina che esegue 120 query è lenta indipendentemente dalla versione di PHP.
• Mantieni PHP aggiornato. Le versioni PHP più recenti sono più veloci e utilizzano meno memoria.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Imposta pm.max_children dalla memoria reale: dividi la memoria che puoi fornire a PHP per la dimensione media di un processo di lavoro (controlla con ps). Con validate_timestamps=0 ricordati di ricaricare PHP-FPM dopo ogni distribuzione, altrimenti il vecchio codice rimane in memoria.

A livello di server Web abilita HTTP/2 o HTTP/3, Brotli o gzip e intestazioni di memorizzazione nella cache di lunga durata per i file statici:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Utilizza nomi di file con versione o una query ?v= basata sull'ora di modifica del file in modo che "immutabile" non offra mai risorse obsolete.

Passaggio 3. Correggere l'elemento LCP

Trova l'elemento LCP in PageSpeed Insights o nel pannello Prestazioni di DevTools. Nella maggior parte delle pagine di contenuto è un'immagine hero. Poi:

• Non caricarlo pigramente. loading="lazy" sull'immagine LCP lo ritarda. Utilizzare invece fetchpriority="high".
• Servire della giusta dimensione. Un'immagine da 2400 px per uno slot da 900 px spreca byte. Utilizza srcset e sizes.
• Utilizza WebP o AVIF. Il risparmio tipico è compreso tra il 30 e il 60% rispetto a JPEG con qualità simile.
• Evitare catene. Un'immagine impostata tramite sfondo CSS o inserita da JavaScript viene scoperta tardi. Inseriscilo nell'HTML come <img>.
• Preconnettersi o ospitare autonomamente origini di terze parti da cui dipende LCP (caratteri, CDN di immagini).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Questo è il modello utilizzato nell'articolo trattato in questo blog: due dimensioni WebP, dimensioni esplicite e priorità di recupero elevata per l'eroe.

Passaggio 4. Rimuovere i turni di layout ( CLS)

• Imposta sempre width e height (o aspect-ratio in CSS) su immagini, video e iframe in modo che il browser riservi lo spazio.
• Riserva spazio per banner, avvisi sui cookie e annunci. Inseriscili in un contenitore con un'altezza minima fissa invece di spingere il contenuto verso il basso dopo il caricamento.
• Caratteri: utilizza font-display: swap o optional, precarica il file del carattere principale e sottoimpostalo. Scegli un carattere di riserva con metriche simili.
• Non inserire contenuto sopra il contenuto esistente a meno che l'utente non lo abbia attivato.
• Anima con transform e opacity, non con proprietà che cambiano il layout (top, height).

Passaggio 5. Migliora INP: meno JavaScript nel thread principale

INP è la metrica più recente e quella trascurata dagli sviluppatori PHP, perché il server non la influenza direttamente. Le cause sono nel browser: attività lunghe da bundle di grandi dimensioni, pesanti script di terze parti (analisi, widget di chat, gestori di tag) e gestori che lavorano troppo in modo sincrono.

• Controlla script di terze parti. Rimuovi ciò che nessuno usa, carica il resto con defer o dopo la prima interazione.
• Suddividi i compiti lunghi. Suddividi il lavoro in blocchi con requestIdleCallback, setTimeout o l' Scheduler API; spostare i calcoli pesanti su un Web Worker.
• Mantieni il DOM piccolo. Migliaia di nodi rallentano ogni aggiornamento.
• Evitare layout sincroni forzati nei loop (leggendo e scrivendo alternativamente le proprietà del layout).
• Mostra un feedback immediato (uno stato premuto o uno spinner) prima di iniziare un lavoro lento.

Passaggio 6. Proteggilo durante il processo di distribuzione

Le prestazioni regrediscono silenziosamente: un nuovo tag, un hero più pesante, una query extra sulla home page. Aggiungi Lighthouse CI o un controllo API PageSpeed pianificato per i tuoi cinque modelli più importanti, imposta i budget ( LCP, dimensione JS totale, peso dell'immagine) e avvisa quando vengono superati. Confronta TTFB prima e dopo ogni rilascio; se salta, la causa è quasi sempre una query o una cache che non va più a buon fine.

Un ordine di lavoro realistico

1. Misura i dati dei campi e identifica i gruppi URL con errori.
2. Abilita OPcache, rivedi le impostazioni PHP-FPM, aggiungi la memorizzazione nella cache dell'intera pagina per il traffico anonimo.
3. Correggi le immagini hero: formato, dimensione, priorità, dimensioni.
4. Prenota spazio per tutto ciò che viene caricato in ritardo.
5. Ridurre e posticipare JavaScript; rimuovere terze parti non utilizzate.
6. Misurare nuovamente dopo 28 giorni, poiché i dati sul campo sono una finestra mobile.

I miglioramenti verranno visualizzati gradualmente in Search Console: il rapporto utilizza all'incirca i dati degli ultimi 28 giorni, quindi una correzione inviata oggi è completamente visibile solo dopo circa un mese.

Come possiamo aiutare

Eseguiamo lavori sulle prestazioni su progetti PHP e Laravel come parte di un impegno SEO tecnico e come messa a punto una tantum: memorizzazione nella cache, query, immagini e correzioni front-end fornite nel codice. Se vuoi sapere quale delle modifiche sopra riportate ripagherebbe il tuo sito, prenota una consulenza o un'analisi del server. Per un elenco di controllo più ampio sulla scansione e l'indicizzazione, leggi il nostro elenco di controllo tecnico SEO.