Core Web Vitals: cosa sono e come migliorarli

I Core Web Vitals sono tre misure con cui Google valuta l’esperienza di chi apre una pagina: quanto tempo serve perché compaia il contenuto principale, quanto la pagina risponde quando tocchi qualcosa e quanto si sposta mentre carica. Si chiamano LCP, INP e CLS, e per ognuna Google indica una soglia “buona”.

In questa guida trovi cosa misura ciascuna, dove leggerle, come sistemare le cause più frequenti e un caso reale su un sito che ho rimesso a posto io, con i numeri presi da Lighthouse prima e dopo. Trovi anche cosa succede al tracciamento di Google Analytics quando fai partire Tag Manager più tardi per guadagnare velocità.

Core Web Vitals: cosa sono le tre misure

Secondo la documentazione di web.dev, i tre valori da tenere sotto controllo sono questi:

• LCP (Largest Contentful Paint): il tempo che passa prima che compaia l’elemento più grande della pagina, di solito la foto principale o il titolo. Buono entro 2,5 secondi.
• INP (Interaction to Next Paint): quanto ci mette la pagina a reagire quando tocchi un pulsante o un menu. Buono entro 200 millisecondi.
• CLS (Cumulative Layout Shift): quanto si spostano gli elementi mentre la pagina carica, come il pulsante che scappa mentre stai per toccarlo. Buono entro 0,1.

Le soglie vanno rispettate sul 75% delle visite, separando telefono e computer. Non basta che il sito sia veloce sul tuo portatile in ufficio.

Contano anche per Google Search: la guida di Google Search Central scrive che, insieme agli altri aspetti dell’esperienza sulla pagina, i Core Web Vitals vanno nella direzione di ciò che i suoi sistemi di ranking premiano. Un punteggio verde non ti porta primo se la pagina non risponde alla ricerca. Una pagina lenta però perde visitatori prima ancora che leggano.

Come misurare i Core Web Vitals

Ci sono due tipi di dati, e confonderli è l’errore più comune.

• Dati sul campo: vengono dalle visite vere degli utenti di Chrome. Li trovi nel report Core Web Vitals di Search Console, che raggruppa le pagine per stato e guarda gli ultimi 28 giorni, e nella parte alta di PageSpeed Insights quando il sito ha abbastanza traffico.
• Dati di laboratorio: un test simulato su un telefono di fascia media, con Lighthouse (dentro Chrome, in Strumenti per sviluppatori → Lighthouse) o nella parte bassa di PageSpeed Insights. Servono per capire le cause, ma variano da un test all’altro.

Nel test di laboratorio l’INP non si può misurare, perché nessuno tocca la pagina. Al suo posto Lighthouse usa il TBT (Total Blocking Time): il tempo in cui il browser è occupato a eseguire codice e non può rispondere. Secondo web.dev un TBT basso va spesso insieme a un INP basso, e l’obiettivo è stare sotto i 200 millisecondi su un telefono medio. Nel punteggio di Lighthouse il TBT pesa il 30%, più di ogni altra misura, come spiega la pagina sul calcolo del punteggio.

Lancia il test almeno tre volte e guarda la media. Un solo test può darti 99 o 79 sulla stessa pagina, l’ho visto succedere sul caso qui sotto. Su un altro sito ho letto 88 e 33 con il computer sotto carico, e 99 sui due lanci successivi.

Come migliorare i Core Web Vitals

Nei siti che ho visto, le cause stanno quasi sempre nel codice e nelle immagini che la pagina carica senza usarli.

LCP alto: la foto principale arriva tardi

1. Servi la foto della misura giusta. Prepara tre versioni (per esempio 480, 720 e 900 pixel di larghezza) e lascia scegliere al browser con srcset. Un telefono non deve scaricare la foto pensata per lo schermo grande.
2. Falla trovare subito. La guida di web.dev sull’LCP consiglia di mettere l’immagine principale nell’HTML iniziale, o di precaricarla con priorità alta (fetchpriority="high").
3. Togli quello che le ruba banda. Loghi del piè di pagina, mappe e immagini sotto la piega si caricano dopo, quando servono.

TBT e INP alti: troppo codice da eseguire

1. Carica solo il codice della pagina aperta. Nei siti costruiti con React o framework simili, la home spesso si porta dietro tutte le altre pagine. Si divide il codice per pagina (in gergo code splitting) e il resto si scarica quando serve.
2. Guarda gli script di terzi. Tag Manager, Analytics, pixel pubblicitari e chat pesano anche loro, e partono presto.

CLS alto: la pagina si sposta

1. Dichiara larghezza e altezza di ogni immagine.
2. Carica subito i font che usi, così il testo non cambia forma a metà caricamento.
3. Non inserire banner o avvisi sopra contenuti già visibili.

Il caso reale: da 81 a 98 su un sito di uno studio dentistico

Lo studio aveva un sito costruito con React. PageSpeed sul telefono dava 74, con LCP a 4,2 secondi. Il test Lighthouse mobile che ho rifatto sul sito online dava 81, con TBT a 700 millisecondi, LCP a 2,2 secondi e CLS a 0.

Le cause, lette nel rapporto di Lighthouse e nel codice:

• Il JavaScript. Il file principale pesava 470 KB e conteneva tutte le pagine, compresi 13 articoli del blog. La home li scaricava ed eseguiva a ogni visita. Ho diviso il codice per pagina: il file della home è sceso a 194 KB.
• La foto principale. Era servita a 900×1200 pixel, 111 KB, anche sul telefono dove occupa circa 370 pixel di larghezza. Con le versioni ridotte, sul telefono la foto è scesa a 32 KB. Le immagini delle mappe delle sedi sono diventate circa il 70% più leggere.
• Il logo del piè di pagina. Veniva precaricato e rubava banda alla foto principale. Ora si carica quando serve.
• I font. Li ho fatti scaricare subito, per evitare lo spostamento del testo quando cambia carattere.

Dopo il primo rilascio, alcune misure davano ancora LCP sopra i 5 secondi. Il motivo erano gli script di Google Tag Manager e Google Analytics, circa 320 KB, che partivano prima che comparisse la foto. Li ho fatti partire 1,5 secondi dopo il caricamento della pagina.

Risultato, con Lighthouse mobile e rallentamento reale di rete e processore (3 misure): punteggio 97-98, TBT 60-90 millisecondi, LCP 2,2 secondi, CLS 0. Con il rallentamento simulato, quello che usa PageSpeed, i risultati restano altalenanti: metà dei test fa 99, l’altra metà circa 79. Per questo il giudizio finale lo danno i dati sul campo di Search Console, tra qualche settimana.

Core Web Vitals e Google Analytics: il prezzo del tracciamento

Spostare Tag Manager più avanti migliora la velocità, ma cambia quello che misuri, e va deciso insieme a chi legge i report.

Nel caso sopra ho controllato sul sito online cosa succede dopo la modifica:

• la visita di pagina in Google Analytics arriva dopo circa 2,4 secondi;
• i clic sul numero di telefono e su WhatsApp restano in coda e vengono inviati appena Tag Manager parte;
• chi chiude la pagina nei primi 2 secondi circa non viene più contato.

Se misuri i contatti con eventi come generate_lead e li colleghi al CRM, come spiego nella guida su Google Analytics e CRM, quella perdita tocca soprattutto le visite che non avrebbero comunque portato un contatto. Ma cambia i totali: dal giorno della modifica le visite calano senza che il sito vada peggio, e chi legge il report deve saperlo. Ne tengo conto anche quando scelgo il modello di attribuzione, perché i confronti a cavallo della modifica non sono più pari. Per l’attribuzione completa ho scritto la guida al modello di attribuzione nel CRM.

Le alternative sono tre:

1. Tag Manager subito: conti tutti, ma paghi in velocità.
2. Tag Manager con un ritardo fisso (come nel caso): perdi solo le uscite immediate.
3. Tag Manager alla prima interazione (scroll, tocco): il più veloce, ma perdi tutte le visite di chi legge senza toccare niente.

Errori da evitare

• Inseguire il 100 di PageSpeed. È un test di laboratorio che varia da una prova all’altra. Conta il verde nei dati sul campo di Search Console.
• Guardare solo il computer. Le soglie vanno rispettate sul telefono, dove la rete è più lenta e il processore più debole.
• Togliere Tag Manager senza dirlo a nessuno. Il sito va più veloce e il giorno dopo i report del marketing mostrano un calo che non esiste.
• Comprimere le immagini e fermarsi lì. Nel caso sopra la differenza più grande l’ha fatta il JavaScript, non le foto.
• Misurare una sola volta dopo la modifica. Un test buono può essere fortuna. Ne servono almeno tre, e poi i dati sul campo.

Domande frequenti

Cosa sono i Core Web Vitals?

Sono tre misure di Google sull’esperienza di chi apre una pagina: LCP (quanto ci mette a comparire il contenuto principale), INP (quanto risponde ai clic) e CLS (quanto si sposta mentre carica). Le soglie buone sono 2,5 secondi, 200 millisecondi e 0,1.

I Core Web Vitals influenzano il posizionamento su Google?

Sì, insieme agli altri aspetti dell’esperienza sulla pagina sono tra le cose che i sistemi di Google premiano. Non bastano da soli: una pagina veloce che non risponde alla ricerca non sale. Una pagina lenta però perde chi arriva dal telefono.

Dove vedo i Core Web Vitals del mio sito?

Nel report Core Web Vitals di Search Console, con i dati delle visite vere degli ultimi 28 giorni. Per capire le cause usa Lighthouse in Chrome o PageSpeed Insights, che fanno un test simulato su un telefono di fascia media.

Perché PageSpeed mi dà un punteggio diverso ogni volta?

Perché è un test di laboratorio: rete, server e processore simulati cambiano da una prova all’altra. Fai almeno tre test e guarda la media. Il giudizio finale lo danno i dati sul campo di Search Console.

Google Tag Manager rallenta il sito?

Può pesare, soprattutto sul tempo in cui il browser è occupato. Puoi farlo partire con un ritardo fisso dopo il caricamento: il sito migliora, ma chi esce nei primi secondi non viene contato. È una scelta da fare insieme a chi legge i report.

Vuoi che il sito porti contatti, non solo punteggi verdi?

La velocità serve se dietro c’è un percorso che trasforma le visite in contatti e i contatti in clienti. Il blueprint qui sotto mette in fila i passaggi che uso per costruirlo. Se i contatti arrivano già ma si perdono nel CRM, la Diagnosi CRM parte da lì.