I Core Web Vitals sono le tre metriche con cui Google misura l'esperienza di chi apre una pagina: LCP per il tempo che serve al contenuto principale per comparire, INP per la reattività ai clic e ai tocchi, CLS per lastabilità del layoutt mentre la pagina finisce di caricare.
Il numero che conta non è quello che vedi lanciando un test dal tuo computer. Google valuta una pagina sui dati raccolti dai visitatori reali di Chrome negli ultimi 28 giorni, e basta una delle tre metriche fuori soglia perché l'intero gruppo di pagine risulti da migliorare.
Che cosa misurano LCP, INP e CLS
Le soglie le pubblica Google e, per sua stessa regola, non cambiano più di una volta all'anno.
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP | Comparsa dell'elemento principale | ≤ 2,5 s | 2,5 - 4 s | > 4 s |
| INP | Risposta alle interazioni | ≤ 200 ms | 200 - 500 ms | > 500 ms |
| CLS | Spostamenti imprevisti del layout | ≤ 0,1 | 0,1 - 0,25 | > 0,25 |
LCP, Largest Contentful Paint, segna il momento in cui l'elemento più grande visibile nella prima schermata finisce di essere disegnato. Quasi sempre è l'immagine di apertura, ed è il motivo per cui peso e formato delle immagini spostano questa metrica più di qualsiasi altra cosa. INP, Interaction to Next Paint, misura il ritardo tra un'interazione e l'aggiornamento visivo che ne consegue, e riporta l'interazione peggiore della visita, non la prima. CLS, Cumulative Layout Shift, è un numero senza unità di misura: il prodotto tra la porzione di schermo che si sposta e la distanza dello spostamento. È la metrica che descrive quel fenomeno per cui stai per premere un pulsante e ne colpisci un altro, una delle frustrazioni più concrete dell'esperienza utente sul web.
Il FID è uscito dai Core Web Vitals a marzo 2024
Il 12 marzo 2024 INP ha sostituito First Input Delay come terza metrica stabile. Nello stesso annuncio il team di Chrome ha fissato una scadenza: il 9 settembre 2024 per togliere il FID da qualsiasi integrazione basata sulle API di CrUX o di PageSpeed Insights, avvisando che sarebbe stata una rottura di compatibilità senza cambio di versione maggiore.
Due anni e mezzo dopo, metà della prima pagina italiana non se n'è accorta. L'articolo di Semrush in quarta posizione porta la data del 7 luglio 2020 e presenta il FID come una delle tre metriche. La pagina di Cloudflare apre scrivendo che i Core Web Vitals «sono: Largest Contentful Paint (LCP), First Input Delay (FID) e Cumulative Layout Shift (CLS)». Serverplan mette FID e INP nella stessa tabella senza dire quale dei due Google usi. Chi legge una di queste pagine e poi va a cercare il FID in Search Console non lo trova, perché non c'è più.
Come Google decide se una pagina passa
Tre meccanismi, tutti scritti nella documentazione e quasi sempre saltati nelle guide.
Il primo: la soglia si applica al 75° percentile dei caricamenti, non alla media, segmentato tra mobile e desktop. Una pagina passa quando tre visite su quattro rientrano nel valore buono, come spiega la documentazione di web.dev.
Il secondo: devono passare tutte e tre. Lo stato di un gruppo è quello della metrica peggiore, scrive la guida di Search Console. CLS scarso e INP buono fanno un gruppo scadente.
Il terzo è il più frainteso. Il report non lavora sui singoli URL ma su gruppi di pagine simili, con l'assunto che condividano lo stesso framework e quindi gli stessi problemi. L'URL che vedi nella tabella è un esempio che rappresenta decine o centinaia di pagine. Per questo l'intervento che sposta il report è quasi sempre sul template, non sulla pagina che hai aperto.
La finestra è di 28 giorni. Un intervento pubblicato oggi entra nei dati a scaglioni e serve circa un mese perché il valore si stabilizzi. Anche la convalida che si avvia dal report di Search Console dura 28 giorni, e una sola istanza del problema rimasta in giro la fa fallire.
Perché PageSpeed Insights ti dà due numeri diversi
In alto, se la pagina ha traffico sufficiente, trovi i dati di campo: quelli raccolti dai browser Chrome degli utenti reali e aggregati nel Chrome User Experience Report. Sono i numeri che finiscono in Search Console e sono quelli che Google usa. Sotto c'è il punteggio da 0 a 100, che nasce da una simulazione di Lighthouse: un caricamento solo, con cache vuota, su un dispositivo e una connessione impostati a tavolino.
I due blocchi possono raccontare storie opposte e non è un difetto degli strumenti. Un punteggio Lighthouse di 95 su una pagina che i tuoi visitatori aprono da uno smartphone di cinque anni fa in 4G non dice niente di utile. Vale anche al contrario: un punteggio mediocre su una pagina che nei dati di campo passa non è un problema da risolvere, e inseguirlo è il modo più comune di bruciare mezza giornata di sviluppo. Su quali interventi conviene davvero spendere tempo lo abbiamo messo in fila nella guida al page speed.
Quanti siti li superano davvero
Il Web Almanac 2025 di HTTP Archive misura l'intera popolazione di siti coperta da CrUX, qualche milione di origini.
| Metrica | Siti con valore buono su mobile | Siti con valore buono su desktop |
|---|---|---|
| Tutti e tre i Core Web Vitals | 48% | 56% |
| LCP | 62% | 74% |
| INP | 77% | 97% |
| CLS | 81% | 72% |
Nel 2021 i siti con Core Web Vitals buoni erano il 32% su mobile e il 41% su desktop, quindi la curva sale. Ma il collo di bottiglia si è spostato. L'interattività su desktop è ormai un problema risolto, passa il 97%. Su mobile il freno è l'LCP: quasi quattro siti su dieci non ci arrivano. E il CLS è l'unica metrica in cui il mobile va meglio del desktop, 81% contro 72%, probabilmente perché su schermo largo ci sono più colonne, più banner e più cose che si muovono.
Un numero smonta un'idea diffusa: i siti grandi non stanno meglio. Tra i primi mille del web passa il 51% su mobile, tra i primi centomila si scende al 37%, sotto la media generale. Più traffico vuol dire più script di terze parti, più gestione dei consensi, più pubblicità.
Da dicembre 2025 LCP e INP si misurano anche fuori da Chrome
Con l'uscita di Safari 26.2, il 12 dicembre 2025, LCP e INP sono diventati Baseline Newly available: la versione corrente di tutti i browser principali espone le API necessarie per misurarli. Era uno degli obiettivi di Interop 2025. Il CLS resta implementato solo nei browser basati su Chromium ed è stato proposto per Interop 2026.
| Metrica | Chrome ed Edge | Safari 26.2 e successivi | Firefox | Finisce in CrUX |
|---|---|---|---|---|
| LCP | Sì | Sì | Sì | Solo da Chrome |
| INP | Sì | Sì | Sì | Solo da Chrome |
| CLS | Sì | No | No | Solo da Chrome |
Sul fronte Google cambia poco: CrUX continua a raccogliere solo da utenti Chrome idonei, quindi Search Console e PageSpeed Insights non vedranno un dato in più. Cambia parecchio se misuri per conto tuo con uno strumento di real user monitoring. Su iOS tutti i browser, Chrome compreso, girano sul motore WebKit e restano fuori da CrUX.
Quanto pesano sul posizionamento
Google consiglia «vivamente» buone metriche di Core Web Vitals e scrive che questo va nella direzione di ciò che i sistemi di ranking principali cercano di premiare. Oltre non va, e non ha mai pubblicato un peso. Chi promette una posizione in cambio di un LCP sotto i 2,5 secondi sta vendendo altro: la velocità è uno dei fattori di ranking, non il primo.
Nella pratica i Core Web Vitals si comportano da discriminante a parità di pertinenza. Contano quando due pagine rispondono alla stessa domanda in modo paragonabile e una delle due risponde male al tocco. Una pagina velocissima con contenuti deboli non supera una pagina lenta che risponde meglio alla query, e nessun lavoro di SEO tecnica compensa un contenuto che non c'entra. Quando seguiamo un progetto di consulenza SEO le performance entrano in scena dopo la struttura e i contenuti, salvo i casi in cui il sito è talmente lento da perdere utenti prima ancora di perdere posizioni.
Resta un punto di cui nel settore si parla poco. Il dato pubblico su cui si basano tutti è cieco su iOS, dove girano anche Chrome e Firefox. Se una quota importante delle tue visite arriva da iPhone, il report di Search Console descrive un pezzo della tua audience e tace sul resto. Da dicembre 2025 quel buco si può coprire con un monitoraggio degli utenti reali basato sulla libreria web-vitals, che ora restituisce LCP e INP anche da Safari. Vale la pena farlo prima che qualcuno si offra di sistemare un LCP che nessuno ha mai misurato sul traffico giusto.
Domande frequenti sui Core Web Vitals
Sono tre: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Il First Input Delay non ne fa più parte: INP lo ha sostituito il 12 marzo 2024 e il supporto al FID negli strumenti Chrome è terminato il 9 settembre 2024.
No. Il punteggio da 0 a 100 viene da una simulazione di Lighthouse su un singolo caricamento. Il verdetto sui Core Web Vitals nasce dai dati di campo del Chrome User Experience Report, raccolti sui visitatori reali. I due valori possono divergere parecchio senza che nessuno dei due sia sbagliato.
La finestra di misurazione è di 28 giorni, quindi un intervento entra nei dati poco alla volta e serve circa un mese perché il valore si stabilizzi. Anche la convalida avviata da Search Console dura 28 giorni.
Secondo il Web Almanac 2025 di HTTP Archive li supera il 48% dei siti su mobile e il 56% su desktop. La metrica che blocca più siti su mobile è l'LCP, con il 62% di valori buoni.
Da Safari 26.2, uscito il 12 dicembre 2025, LCP e INP sono misurabili su tutti i browser principali. Il CLS resta disponibile solo nei browser basati su Chromium. I dati di CrUX, però, continuano ad arrivare solo da Chrome.
