La guida per sviluppatori ai Core Web Vitals

I Core Web Vitals sono il tentativo di Google di quantificare la percezione di "velocità" e incidono direttamente sul posizionamento nei risultati di ricerca. Sono tre: LCP misura il caricamento, INP misura la reattività e CLS misura la stabilità visiva. Superarli non è una questione di trucchi: richiede di capire cosa misura ciascuna metrica e di correggere i problemi specifici che la penalizzano.

LCP, Largest Contentful Paint

LCP è il tempo necessario perché l'elemento più grande nel viewport (di solito un'immagine hero o un blocco titolo) termini il rendering. L'obiettivo è sotto i 2,5 secondi. Le cause più comuni di un LCP negativo:

• Un'immagine hero grande e non ottimizzata
• CSS o JavaScript render-blocking nel <head>
• Risposta lenta del server (TTFB elevato)
• Web font che ritardano il rendering del testo

Le correzioni: servire immagini in formati moderni (WebP/AVIF) alle dimensioni corrette, fare il preload dell'immagine LCP, inline del CSS critico e rendering HTML lato server in modo che il browser abbia qualcosa da dipingere immediatamente. Se il TTFB è alto, il problema è a monte — caching o hosting — non nel front end.

INP, Interaction to Next Paint

INP ha sostituito il First Input Delay ed è più esigente. Misura la latenza delle interazioni sull'intera visita alla pagina: si clicca un pulsante, quanto tempo passa prima che lo schermo risponda visibilmente? L'obiettivo è sotto i 200 millisecondi. Un INP negativo è quasi sempre sintomo del main thread bloccato da JavaScript.

Le correzioni:

• Suddividere i task lunghi in modo che il browser possa rispondere tra un'esecuzione e l'altra
• Ridurre la quantità di JavaScript, applicare il code-splitting e il lazy-load per ciò che non serve al primo caricamento
• Differire il lavoro non critico con requestIdleCallback o cedendo il controllo al main thread
• Evitare operazioni sincrone pesanti negli event handler

INP è la metrica in cui più siti falliscono dopo il recente cambiamento di Google, ed è solitamente un sintomo di troppo JavaScript lato client.

CLS, Cumulative Layout Shift

CLS misura i movimenti inattesi: i contenuti che saltano mentre la pagina si carica. L'obiettivo è sotto 0.1. I soliti responsabili:

• Immagini ed embed senza attributi width e height
• Annunci o banner inseriti sopra contenuti già presenti
• Web font che causano un reflow quando vengono sostituiti
• Contenuti inseriti dinamicamente senza spazio riservato

Le correzioni: impostare sempre dimensioni esplicite o un aspect-ratio sui media, riservare lo spazio per tutto ciò che si carica in ritardo e fare il preload dei font scegliendo deliberatamente tra font-display: optional o swap.

Misurare con gli strumenti giusti

C'è una distinzione fondamentale: i field data (utenti reali, nel report CrUX di Google) sono quelli che incidono realmente sul ranking, mentre i lab data (Lighthouse, una singola esecuzione sintetica) sono soltanto uno strumento diagnostico. Un punteggio verde su Lighthouse non vale nulla se gli utenti reali su dispositivi lenti falliscono le metriche.

1. Usare PageSpeed Insights per vedere sia i field data sia i lab data per un URL.
2. Usare la libreria JavaScript web-vitals per raccogliere INP e LCP reali dai propri utenti.
3. Monitorare il report Core Web Vitals di Search Console per osservare i trend sull'intero sito.

L'ordine delle operazioni

Correggere prima LCP (di solito è il guadagno maggiore e riguarda SSR e immagini), poi INP (ridurre JavaScript), poi CLS (riservare spazio nel layout). Va trattato come un'igiene continua, non come un audit una tantum: un singolo script di terze parti pesante può vanificare mesi di lavoro.

Se Search Console segnala vitali in rosso e si vuole portarli al verde senza riscrivere tutto, parliamone.