I Core Web Vitals sono tre metriche con cui Google misura l'esperienza di caricamento e di interazione degli utenti reali. Non sono un punteggio estetico: sono numeri con soglie precise, e ciascuno peggiora per cause tecniche diverse. Confonderle è il motivo per cui molte ottimizzazioni non spostano nulla.

Le tre metriche e le soglie

  • LCP (Largest Contentful Paint): quando compare l'elemento di contenuto più grande della viewport. Obiettivo: sotto 2,5 s.
  • INP (Interaction to Next Paint): quanto tempo passa tra un'interazione dell'utente e il primo aggiornamento visibile, considerando le interazioni peggiori della visita. Obiettivo: sotto 200 ms.
  • CLS (Cumulative Layout Shift): quanto il layout si sposta durante il caricamento. Obiettivo: sotto 0,1.

Dettaglio che cambia il modo di leggerli: la valutazione si basa sul 75° percentile delle visite reali raccolte su 28 giorni. Non conta la media, conta che tre visite su quattro stiano sotto la soglia - motivo per cui i dispositivi lenti e le connessioni scadenti pesano molto più di quanto sembri provando il sito dal proprio portatile.

Cosa peggiora LCP

Nell'ordine in cui vale la pena controllarli: il tempo di risposta del server (se il TTFB è già di un secondo, il resto è quasi ininfluente); le risorse che bloccano il rendering, cioè CSS e script sincroni nell'head; l'immagine principale scoperta tardi dal browser perché caricata via CSS o marcata loading="lazy" - proprio l'elemento LCP è l'unico che non va mai in lazy, e semmai va anticipato con fetchpriority="high"; infine i font, se il testo resta invisibile in attesa del download.

Cosa peggiora INP

Una sola causa dominante: attività JavaScript lunghe sul thread principale. Finché un task occupa il thread, il browser non può rispondere al clic né ridisegnare. Gli interventi efficaci sono spezzare i task lunghi, ridurre il lavoro fatto negli handler, evitare letture di layout che forzano ricalcoli sincroni e rimandare tutto ciò che non serve alla prima interazione.

Cosa peggiora CLS

Elementi che cambiano dimensione o posizione dopo essere stati disegnati: immagini e iframe senza width e height (o senza aspect-ratio), font di ripiego con metriche diverse da quello definitivo, contenuti inseriti sopra a quelli già visibili - banner, avvisi, pubblicità. La regola è riservare lo spazio prima, non dopo.

Laboratorio e campo non misurano la stessa cosa

Lighthouse esegue una simulazione su un dispositivo e una rete ipotetici: è utile per diagnosticare, perché isola le cause. I dati di campo (quelli che Google usa davvero) vengono dai browser degli utenti reali, con i loro dispositivi e le loro connessioni. Un punteggio di laboratorio quasi perfetto e Core Web Vitals non superati sul campo è una combinazione normale, non un errore di misura: significa che gli utenti reali non assomigliano alla simulazione.

L'ordine degli interventi

Si misura, si isola il collo di bottiglia (server, risorse bloccanti o JavaScript), si cambia una cosa alla volta e si rimisura. Va tenuto presente che le metriche possono muoversi in direzioni opposte: rimandare l'esecuzione di script migliora l'LCP ma può peggiorare l'INP, perché il lavoro rimandato si accumula e ricade proprio sulla prima interazione dell'utente. E sul campo il risultato di una modifica si legge dopo che la finestra di 28 giorni si è aggiornata: prima di allora si stanno guardando dati vecchi.

Collegato: su misura o no-code incide direttamente sul peso del codice servito.