Core Web Vitals spiegati da uno sviluppatore: dati reali, attribuzione e cause profonde

I Core Web Vitals sono tre metriche con cui Google misura l'esperienza reale di caricamento, reattività e stabilità visiva: LCP, INP e CLS. Le definizioni si trovano ovunque. Qui mi interessa altro: come si leggono i dati in modo corretto, come si risale alla causa di una metrica cattiva e perché tanti interventi «da checklist» non spostano nulla.

Dati di campo e dati di laboratorio

È la distinzione che risolve metà delle discussioni.

• Dati di campo (CrUX): raccolti da Chrome su utenti reali, aggregati su 28 giorni, valutati al 75° percentile. Sono quelli usati da Search Console e da Google. Rispecchiano dispositivi, reti e comportamenti veri, ma arrivano in ritardo e solo per pagine o origini con abbastanza traffico.
• Dati di laboratorio (Lighthouse): un caricamento simulato su un dispositivo e una rete fissi. Utili per diagnosticare e confrontare versioni, ma non misurano l'INP (al suo posto c'è il TBT) e non vedono ciò che succede dopo il caricamento.

Un punteggio Lighthouse di 95 con un INP di campo a 400 ms non è una contraddizione: il test di laboratorio non ha mai cliccato niente. Per capire davvero cosa succede servono dati di campo propri, raccolti con la libreria web-vitals nella build di attribuzione e inviati a uno strumento di analisi.

LCP: scomporlo prima di ottimizzarlo

L'LCP misura quando viene disegnato l'elemento più grande nella finestra iniziale. Dire «l'LCP è 3,8 secondi» non basta: va scomposto in quattro sottoparti.

1. TTFB: quanto ci mette il server a mandare il primo byte dell'HTML.
2. Ritardo di caricamento della risorsa: tempo tra il TTFB e l'inizio del download dell'immagine o del font dell'elemento LCP.
3. Durata del caricamento della risorsa: quanto dura quel download.
4. Ritardo di rendering: tempo tra la fine del download e il disegno effettivo.

In un sito sano le due parti di «ritardo» sono piccole. Nella pratica, il problema più frequente che trovo non è un'immagine pesante ma un ritardo di caricamento alto: l'immagine LCP è un background CSS, viene inserita da JavaScript, ha loading="lazy" o è scoperta solo dopo che uno slider si è inizializzato. Il browser la trova tardi. La soluzione è renderla scopribile nell'HTML iniziale e darle fetchpriority="high", non comprimerla di un altro 10%.

Se invece domina il TTFB, il problema è lato server o di architettura: generazione dinamica lenta, cache assente, redirect a catena. Un sito generato in anticipo e servito da CDN ha un TTFB vicino al minimo fisico.

Il ritardo di rendering alto indica CSS o JavaScript che bloccano il disegno, o un font web necessario all'elemento LCP che arriva tardi.

INP: è un problema di thread principale

L'INP misura la latenza delle interazioni (clic, tocchi, tasti) lungo tutta la visita e riporta, in sostanza, la peggiore. Ogni interazione ha tre fasi:

• ritardo di input: il thread principale è occupato e l'evento aspetta;
• tempo di elaborazione: i gestori di evento girano;
• ritardo di presentazione: il browser ricalcola stili e layout e disegna il frame successivo.

La causa quasi universale di un INP cattivo sono i long task, blocchi di JavaScript oltre i 50 ms che occupano il thread principale. Da dove vengono:

• script di terze parti (tag manager, chat, analytics multipli, pixel) che si eseguono durante la navigazione;
• page builder e framework che idratano tutta la pagina all'avvio;
• gestori di evento che fanno troppo lavoro in modo sincrono, per esempio filtrare una lista intera a ogni tasto;
• DOM enormi, per cui ogni ricalcolo di stile e layout costa decine di millisecondi.

L'API Long Animation Frames e l'attribuzione di web-vitals dicono quale script, quale funzione e quale elemento hanno causato l'interazione lenta. Senza attribuzione si va per tentativi.

Le correzioni efficaci sono strutturali: spezzare il lavoro e cedere il thread (scheduler.yield() dove disponibile), rimandare il lavoro non urgente dopo il disegno del frame, ridurre il DOM, caricare le terze parti solo quando servono. Un plugin che «ritarda tutti gli script» migliora i dati di laboratorio e spesso peggiora l'INP, perché sposta l'esecuzione proprio nel momento della prima interazione.

CLS: spostamenti con un colpevole preciso

Il CLS somma gli spostamenti inattesi del layout, raggruppati in finestre. Il pannello Performance e l'attribuzione di web-vitals indicano l'elemento spostato e quello che ha causato lo spostamento. Le cause reali, nell'ordine in cui le incontro:

• contenuti inseriti sopra il contenuto esistente: banner cookie in cima, avvisi, annunci;
• immagini, iframe e video senza dimensioni o senza aspect-ratio;
• font web con metriche diverse dal fallback: si correggono con size-adjust e affini, non solo con font-display;
• animazioni di proprietà che causano layout (top, height) invece di transform;
• componenti che si idratano e cambiano altezza dopo il primo disegno.

Attenzione anche alla cache bfcache: pagine escluse dal back/forward cache ricaricano tutto a ogni «indietro» e rigenerano spostamenti che non dovrebbero esistere.

Come imposto il lavoro

1. Search Console e CrUX per sapere quale metrica, su quale dispositivo e su quale gruppo di pagine.
2. Raccolta di dati di campo propri con attribuzione, se il traffico lo permette.
3. Riproduzione in laboratorio con CPU rallentata e trace del pannello Performance.
4. Intervento sulla sottoparte o sulla fase dominante, non su tutto insieme.
5. Verifica sui dati di campo dopo almeno 28 giorni, perché CrUX è una media mobile.

Come la vedo io

I Core Web Vitals premiano le architetture semplici. Le pagine statiche servite da CDN partono con un TTFB minimo, un HTML che contiene già l'elemento LCP e poco JavaScript da eseguire. È il motivo per cui costruisco i siti nuovi con Nuxt, generazione in fase di build e Tailwind, che produce solo il CSS usato: buona parte dei problemi di questo articolo non si presenta proprio.

Su WordPress si può arrivare a buoni valori, e lo faccio, ma con un tema multiuso, un builder e decine di plugin si combatte contro la struttura. Ne parlo in Sito WordPress lento: un'analisi tecnica e, per chi valuta di cambiare, in Da WordPress a Nuxt, GitHub e Netlify.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. Lavoro sui Core Web Vitals partendo dai dati di campo e dall'attribuzione, non dal punteggio.

Se Search Console ti segnala problemi, scrivimi: in una chiacchierata di circa 20 minuti guardiamo quale metrica soffre e perché. Il servizio è in Velocità e SEO.