Core Web Vitals: cosa sono e quanto contano davvero

I Core Web Vitals sono tre metriche che Google raccoglie dai visitatori reali di Chrome per misurare la velocità di caricamento, la reattività e la stabilità visiva di una pagina: LCP, INP e CLS. In italiano circolano anche come «segnali web essenziali»: sono le stesse tre.

Le soglie sono 2,5 secondi per l’LCP, 200 millisecondi per l’INP e 0,1 per il CLS, verificate al 75° percentile delle esperienze reali su una finestra di 28 giorni, mobile e desktop a parte. Il punteggio 0-100 di PageSpeed Insights non è un Core Web Vital: è un indice di laboratorio, e sulla stessa pagina può raccontare una storia diversa dal dato di campo. Se il sito ha poco traffico i Core Web Vitals non ce li hai proprio, perché nessuno li ha misurati.

Sul posizionamento pesano dentro i segnali di page experience, dopo la pertinenza del contenuto, e Google lo mette per iscritto.

Cosa sono i Core Web Vitals (o segnali web essenziali)

Tre metriche, misurate sui visitatori veri di Chrome e non su una simulazione: LCP (Largest Contentful Paint) per la velocità con cui compare il contenuto principale, INP (Interaction to Next Paint) per la reattività ai clic e ai tap, CLS (Cumulative Layout Shift) per quanto il layout balla sotto le dita. Sono tre e sono stabili: nel set non c’è nessuna metrica sperimentale in lista d’attesa, come si legge nella definizione su web.dev.

«Segnali web essenziali» è la variante che si incontra più spesso nelle guide italiane. Google però, nella sua Guida di Search Console in italiano, apre la pagina del report con un H1 che dice «Report Core Web Vitals». «Segnali web essenziali» ci compare una volta sola in tutto il documento, ed è Google che chiama così il proprio report, in una nota su PageSpeed Insights: «le informazioni in PageSpeed Insights potrebbero variare rispetto a quelle presenti nel report Segnali web essenziali». Anche la documentazione di Search Central in italiano tiene la dicitura inglese. Se cerchi una delle due e trovi l’altra, sei nel posto giusto.

Il dato non nasce in Search Console ma nel Chrome User Experience Report, CrUX per gli amici: lì Chrome deposita le esperienze degli utenti che hanno acconsentito a mandarle, e da lì lo pescano sia Search Console sia PageSpeed Insights.

LCP, INP e CLS: cosa misura ciascuna

LCP. Il tempo che passa da quando l’utente chiede l’URL a quando compare l’elemento di contenuto più grande nell’area visibile. Più grande, non più pesante: sembra una pedanteria e invece sposta l’attenzione dal file da comprimere all’elemento da mostrare prima. Di solito è un’immagine, un video o un blocco di testo, e cambia con il viewport.

INP. La latenza dell’interazione, dal clic (o dal tap, o dalla pressione di un tasto) al frame successivo che il browser disegna davvero. Copre l’intero ciclo di vita della pagina, dal primo tap all’ultimo: se l’utente resta dieci minuti e clicca trenta volte, l’INP ha guardato tutte e trenta le volte.

CLS. Quanto il layout si sposta mentre la pagina è visibile, in un punteggio senza unità di misura. Il valore che conta è quello della raffica di spostamenti peggiore.

Le soglie di LCP, INP e CLS

Tre fasce per tre metriche, con i nomi italiani che leggi in Search Console. Le riporta la Guida di Search Console.

Due letture che la tabella da sola non dà. La fascia peggiore decide, quindi un LCP da record con un CLS a 0,3 resta un gruppo di URL in fascia scadente. E mobile e desktop hanno verdetti separati: la stessa pagina può stare in «Buono» sul telefono e in «Richiede miglioramenti» sul computer, sempre secondo la Guida.

Il punteggio di PageSpeed Insights non è un Core Web Vital

No, e questa è la confusione che manda in vacca il resto. Il numero grande in cima a PageSpeed Insights è il punteggio di prestazioni di Lighthouse, un indice sintetico calcolato in laboratorio su una sola esecuzione simulata. I Core Web Vitals stanno più sotto, nel blocco che riguarda gli utenti reali, e se quel blocco non c’è vuol dire che non ce ne sono.

PageSpeed Insights su donatopirolo.dev/seo-per-ai/, mobile, 29 agosto 2026, Lighthouse 13.4.1: prestazioni 66 su 100, LCP di laboratorio 6,1 s, FCP 3,4 s, CLS 0, TBT 130 ms, Speed Index 5,4 s, risposta del documento root in 10 ms. Il blocco degli utenti reali non compare: l’API restituisce il solo indirizzo iniziale, senza una metrica, e la sezione a livello di origine è assente. Nessuno di quei numeri è un Core Web Vital.

Il giorno dopo, 30 agosto 2026, quattro pagine dello stesso dominio: stesso tema, stesso hosting, stesso strumento.

Pagine di testo con tre immagini WebP da 16-78 KB, zero video, zero pubblicità, e nessuna delle quattro sta sotto i 2,5 s. Chi promette «comprimi le immagini e sei a posto» non ha guardato una pagina vera. Qui il problema è aperto, non risolto.

Il TBT è il numero più frainteso della lista. In laboratorio l’INP non si misura: senza qualcuno che clicca non c’è interazione da cronometrare, e il Total Blocking Time è il surrogato di Lighthouse. Un TBT buono non promette un INP buono.

Perché due strumenti Google danno numeri diversi sulla stessa pagina

Perché misurano cose diverse, in momenti diversi, su due popolazioni che non si somigliano. Le elenca la pagina di web.dev sulle differenze fra dati di laboratorio e dati di campo.

• La cache. Il laboratorio parte sempre a freddo; i tuoi utenti arrivano in buona parte con font, CSS e immagini già in memoria.
• Il dispositivo e la rete. PageSpeed Insights simula un telefono di fascia media su connessione rallentata. I tuoi visitatori sono un miscuglio di iPhone recenti e Android di sei anni fa, su fibra e su 3G di montagna.
• L’elemento LCP cambia. Con un viewport diverso, o con l’utente loggato, il contenuto più grande nell’area visibile è un altro.
• L’INP non è misurabile in laboratorio. Serve qualcuno che interagisca.
• Il CLS di laboratorio si ferma al caricamento. Sul campo conta anche quello che si sposta mentre l’utente scorre.
• I ripristini da bfcache. Quando l’utente torna indietro CrUX registra quella visita, il laboratorio no.

Poi c’è la granularità, e la scrive Google nella Guida del report: le metriche dei Core Web Vitals combinano dati e stato in gruppi di URL, PageSpeed Insights mostra in genere il singolo URL, e «un singolo URL potrebbe essere un valore anomalo nel proprio gruppo». Sempre lì: gli URL del report includono i parametri quando distinguono la pagina, PageSpeed Insights li toglie.

Anche il solo laboratorio balla: /seo-per-ai/ fa 66 il 29 agosto e 76 il 30, misurata con lo stesso strumento, senza che in mezzo io abbia toccato una riga di codice.

Come Google valuta davvero: 75° percentile e 28 giorni

Al 75° percentile delle esperienze reali degli ultimi 28 giorni, separando mobile e desktop. Una media, o un singolo test fatto dal divano, misurano un’altra cosa. La Guida di Search Console lo dice metrica per metrica: l’LCP del gruppo «indica il tempo massimo impiegato per la visualizzazione del Largest Contentful Paint per il 75% delle richieste di pagine negli ultimi 28 giorni». Tre quarti delle visite devono stare sotto la soglia.

La finestra mobile di 28 giorni spiega la domanda più frequente, quella del fix che non si vede: il giorno dopo l’intervento il report contiene ancora ventisette giorni di prima. E quando avvii la convalida, Search Console apre «una sessione di monitoraggio di 28 giorni», che si chiude solo se il problema non ricompare su nessun URL. Un mese e mezzo fra correzione e spunta verde è la normalità.

Poi c’è quella che fa litigare i team: lo stato appartiene al gruppo di pagine con esperienza utente simile in cui Google ha infilato la tua URL. Il report, scrive Google, mostra «un campione di pagine»; i dati vengono assegnati all’URL effettivo, non a quello canonico, al contrario di quasi tutti gli altri rapporti. La tua pagina può comparire come esempio di un problema che ha il vicino di scaffale.

CrUX tiene i dati per singola URL quando ce ne sono abbastanza, e altrimenti ripiega sull’origine, cioè su tutto il dominio: lì il tuo articolo nuovo eredita la media del sito.

Quando il tuo sito non è in CrUX

Allora i Core Web Vitals non ce li hai: non ne hai di cattivi, non ne hai affatto. È il caso di moltissimi siti piccoli, compreso il mio.

La CrUX API interrogata su donatopirolo.dev il 29 agosto 2026, form factor PHONE, risponde 404 con il messaggio chrome ux report data not found sull’URL https://donatopirolo.dev/seo-per-ai/. Rilanciata sull’origine https://donatopirolo.dev, stesso 404: il ripiego sull’origine, che di solito salva le pagine nuove, qui non ha niente su cui ripiegare.

La regola sta nella metodologia di CrUX: una pagina entra nel dataset se è pubblicamente rilevabile e ha un numero minimo di visitatori. Quel numero Google non lo pubblica, e sulla stessa pagina scrive di averlo scelto per avere abbastanza campioni da fidarsi della distribuzione statistica delle pagine incluse. La soglia è la stessa per le pagine e per le origini, e a livello di origine Google somma le esperienze di tutte le pagine del sito.

La conseguenza è liberatoria e scomoda insieme: senza dati di campo non c’è un valore che possa pesare, come non pesa un compito in bianco, ma nemmeno tu sai come vanno le cose, e il 66 di PageSpeed Insights non lo sa per te.

L’unica uscita è il monitoraggio degli utenti reali. Prima però la verifica da trenta secondi, con una chiave della CrUX API:

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=LA_TUA_CHIAVE" \
  -H "Content-Type: application/json" \
  -d '{"origin":"https://iltuosito.it","formFactor":"PHONE"}'

Se torna un 404 come il mio, il problema non sono le soglie: è il traffico.

Quanto pesano davvero sul ranking

Contano, e non ribaltano la pertinenza: sono un fattore di ranking, ma l’ultimo a parlare.

Le righe che rispondono stanno nella FAQ della pagina sulla page experience, in italiano. Sulle metriche: «Le metriche di Core Web Vitals vengono utilizzate dai nostri sistemi di ranking». Sull’esistenza di un segnale unico: «No, non esiste un singolo indicatore; i nostri sistemi principali di ranking esaminano una varietà di indicatori in linea con l’esperienza sulle pagine complessiva».

Poi la riga che mette i fattori in ordine: «La Ricerca Google cerca sempre di mostrare i contenuti più pertinenti, anche se l’esperienza sulle pagine è di qualità scadente. Tuttavia, per molte query sono disponibili tanti contenuti utili. Un’esperienza sulle pagine eccellente può contribuire al successo nella Ricerca, in questi casi».

E lì sta anche l’avvertenza più utile a chi guarda i grafici: «Tieni presente che avere buoni risultati in report come i report Core Web Vitals di Search Console o strumenti di terze parti non garantiscono che le tue pagine si posizioneranno in cima ai risultati della Ricerca Google».

L’idea per cui un sito con contenuti perfetti ma lento verrebbe penalizzato comunque dice il contrario di quanto sta scritto lì. Se sei tredicesimo per un articolo che risponde a metà della domanda, il problema non è l’LCP.

Come si scompone ogni Core Web Vital

Ogni Core Web Vital si scompone in sotto-parti misurabili, e l’unico intervento sensato è quello sulla sotto-parte che si sta prendendo il tempo. È il framework diagnostico della documentazione Chrome, ed è il motivo per cui le checklist generiche funzionano per caso: «migliora l’LCP» ammette quattro diagnosi diverse.

Le quattro parti dell’LCP

TTFB, resource load delay, resource load duration ed element render delay: l’LCP è la somma di questi quattro tempi, e la guida all’LCP di Chrome dà pure la ripartizione a cui puntare.

• TTFB, il tempo fino al primo byte: circa il 40% dell’LCP.
• Resource load delay, l’attesa fra il primo byte e l’inizio del caricamento della risorsa LCP: sotto il 10%.
• Resource load duration, il tempo per scaricare la risorsa: circa il 40%.
• Element render delay, l’attesa fra risorsa pronta ed elemento disegnato: sotto il 10%.

La diagnosi cambia il lavoro. Un 40% di TTFB manda a guardare server, cache e reindirizzamenti. Un 40% di render delay manda a guardare il CSS bloccante, i font e il JavaScript che tiene occupato il thread principale mentre l’immagine sta già lì, pronta e invisibile. Un load delay alto vuol dire che il browser ha scoperto la risorsa tardi, perché referenziata da un foglio di stile o iniettata da uno script.

Sul mio caso il conto si chiude da solo: LCP di laboratorio a 6,1 s con il documento root che risponde in 10 ms. Il collo di bottiglia non è l’hosting, e cambiare server significherebbe pagare per un numero già a posto.

Le tre parti dell’INP

Input delay, processing duration e presentation delay, secondo la guida all’INP. Il primo è il tempo fra l’interazione e l’avvio dei gestori di evento, il secondo è l’esecuzione dei gestori, il terzo è quello che serve al browser per calcolare il layout e dipingere il frame successivo.

defer e async, il consiglio standard di ogni guida, sull’INP non fanno quasi niente: decidono quando uno script viene scaricato ed eseguito durante il caricamento. L’INP si misura mentre l’utente sta usando la pagina, magari dopo tre minuti, e rimandare uno script all’inizio non alleggerisce il gestore del clic.

L’INP colpisce soprattutto le single page application e i siti costruiti sui framework JavaScript. Lì un tap è un evento che innesca aggiornamento di stato, ricalcolo e nuovo rendering, tutto nel thread principale, nello spazio fra il dito e il frame che deve comparire. Un sito statico parte avvantaggiato senza aver fatto nulla.

Il CLS conta la raffica di spostamenti peggiore

Il punteggio è quello della finestra di sessione peggiore: un gruppo di spostamenti separati da meno di 1 secondo l’uno dall’altro, per un massimo di 5 secondi complessivi. Sta nella definizione ufficiale del CLS, che segnala anche la formula precedente, quella a somma totale. Il cambio è del giugno 2021, come registra la nota in coda a «Evolving the CLS metric».

La formula che trovi ancora in giro, la somma di tutti gli spostamenti dell’intera visita, è superata da cinque anni e porta a scegliere gli interventi sbagliati: la somma premia chi ha pochi spostamenti, la raffica peggiore punisce chi ne ha uno solo, grosso e concentrato.

La conseguenza riguarda il pezzo di pagina che tutti hanno. Un cookie banner che spinge giù l’intero contenuto in una volta sola può valere più di dieci micro-assestamenti sparsi lungo lo scorrimento: quei dieci finiscono in finestre diverse, il banner fa una raffica sola e altissima. Riservargli lo spazio, o sovrapporlo al contenuto, vale più di qualunque compressione di immagini.

Gli spostamenti che arrivano entro 500 millisecondi da un input ricevono il flag hadRecentInput e restano fuori dal conto, ma solo per gli input discreti: tap, clic, pressione di un tasto. Lo scorrimento, il trascinamento e il pinch to zoom non valgono come input recente, e quello che si sposta durante uno scroll entra nel punteggio. Un accordion aperto con un clic non è un problema di CLS; un banner che si infila nella pagina mentre l’utente scorre lo è.

Come migliorare i Core Web Vitals, ordinati per la parte che curano

Ordinati per la sotto-parte che stai cercando di accorciare, unico criterio che regge quando gli interventi sono venti e il tempo è poco.

Un avvertimento sulla portata: nessuna delle quattro pagine misurate più sopra sta sotto i 2,5 secondi di LCP. Quello che segue è l’ordine in cui la documentazione Chrome mette gli interventi, ed è il punto da cui parto anch’io.

Per l’LCP.

• Sull’immagine principale dell’area visibile va fetchpriority="high": dice al browser di scaricarla prima delle altre.
• Mai loading="lazy" sull’elemento LCP. La documentazione Chrome lo scrive senza sfumature, ed è uno dei modi più efficaci per peggiorare da soli.
• Quando la risorsa è referenziata solo dal CSS o da uno script il browser la scopre tardi, e allora serve il preload.
• Usa formati moderni veri, WebP e AVIF. JPEG 2000 e JPEG XR, ancora raccomandati da qualche guida italiana, oggi non li apre nessun browser: le tabelle di supporto di caniuse danno il primo fuori anche da Safari dalla versione 18, il secondo fermo all’Edge di prima del 2020.

Per l’INP.

• Spezza i task lunghi e cedi il thread principale fra un pezzo e l’altro. L’API dedicata è scheduler.yield(), che web.dev documenta nella guida sull’ottimizzazione dei task lunghi.
• Alleggerisci i gestori di evento: aggiorna subito quel che l’utente deve vedere, rimanda il resto.
• Ogni nodo del DOM in più costa a ogni ricalcolo, quindi ridurne il numero paga su tutte le interazioni.
• Applica content-visibility alle sezioni fuori schermo.

Per il CLS.

• Dichiara larghezza e altezza su immagini e iframe, oppure imposta aspect-ratio.
• Lo spazio per banner, widget e pubblicità va riservato prima che arrivino.
• Il cambio di font può riscrivere mezza pagina: si governa con font-display.

Restano due leve strutturali che valgono su tutte e tre le metriche. Il bfcache ripristina la pagina precedente quasi istantaneamente quando l’utente torna indietro, e CrUX conta quei ripristini come visite. Su desktop Chrome e Firefox rendono non idonea la pagina che aggiunge un listener unload. Su mobile Chrome e Safari provano a metterla in cache lo stesso, perché lì quell’evento è sempre stato inaffidabile; Firefox invece la tratta come non idonea anche su mobile, tranne su iOS, dove tutti i browser girano sul motore WebKit e si comportano come Safari. Con Cache-Control: no-store sulla risorsa della pagina i browser storicamente hanno scelto di non metterla in bfcache, quindi la pagina può risultare non idonea; per Chrome è in corso un lavoro per cambiare quel comportamento. Sono le condizioni della documentazione di Chrome sul bfcache; lo stato della tua pagina lo verifichi in Chrome DevTools, sotto Application → Back-forward Cache.

L’altra leva sono le Speculation Rules: dichiari quali pagine il browser deve prerenderizzare, e su una pagina già renderizzata l’LCP arriva quasi a zero. La documentazione Chrome raccomanda di limitarle ai casi in cui la navigazione è molto probabile, altrimenti scarichi con la banda di qualcun altro pagine che nessuno aprirà.

Core Web Vitals su WordPress: cosa cambia davvero

Poco, e sempre negli stessi due punti. L’LCP si gioca nel template o nel blocco dell’immagine in cima: fetchpriority="high" e dimensioni dichiarate vanno lì, e lì va tolto il caricamento differito che il tema applica a tappeto. L’INP è quasi sempre dominato dagli script di terze parti che il tema carica ovunque, compresi quelli che servono a una sola sezione.

Il criterio non cambia: si guarda quale sotto-parte è lenta e si interviene lì. Un plugin di ottimizzazione sopra un tema che carica sei librerie su ogni vista sposta il problema di una casella.

Come misurare i Core Web Vitals: gli strumenti nell’ordine in cui servono

L’ordine conta più dell’elenco: ogni strumento risponde a una domanda diversa, e usarli fuori sequenza costa un pomeriggio.

1. Search Console, rapporto Core Web Vitals. Risponde a «quali gruppi di pagine hanno un problema», ed è l’unico che ragiona per gruppi.
2. CrUX, interfaccia o API. Risponde a «qual è il dato di campo di questa URL e di questa origine». La CrUX Dashboard, che qualche guida cita ancora, è stata dismessa a novembre 2025, annunciata l’agosto prima.
3. Chrome DevTools, pannello Performance. Risponde a «perché». Dal 17 settembre 2024 affianca ai Core Web Vitals locali, misurati mentre navighi, i dati di campo di CrUX per pagina e per origine; indica l’elemento LCP e lo rende cliccabile nel DOM; tiene un log delle interazioni con la loro latenza.
4. La libreria web-vitals in attribution build. Risponde a «quale elemento» e «quale interazione», sugli utenti veri. Per un chilobyte e mezzo in più restituisce l’elemento LCP con le sue quattro sotto-parti, l’interazione peggiore con le sue tre, e il selettore dello shift più grande per il CLS. Repository GoogleChrome/web-vitals, versione maggiore corrente la 5.
5. La Long Animation Frames API. Risponde a «quale script». Da Chrome 123, registra i frame che superano i 50 ms ed espone blockingDuration e un array scripts con sourceURL e sourceFunctionName.

Per un sito senza dati CrUX i primi due passaggi non danno niente e si parte dal quarto: la libreria raccoglie sui tuoi visitatori quello che il dataset pubblico non ha volume per contenere.

Tre cose che si leggono in giro

Tre affermazioni ricorrenti, e cosa dicono davvero le pagine ufficiali.

I crawler AI preferiscono i siti veloci. La pagina di Google sulle funzionalità AI nella Ricerca è netta: «Non sono previsti requisiti aggiuntivi per la visualizzazione in AI Overview o in AI Mode, né sono necessarie altre ottimizzazioni speciali». L’unica condizione tecnica è che la pagina sia indicizzata e idonea a comparire in Ricerca con uno snippet; velocità e Core Web Vitals non compaiono. L’esperienza sulle pagine eccellente lì c’è, ma nell’elenco delle best practice SEO, non fra i requisiti. Cosa chieda davvero l’ho scritto in SEO per le AI.

La valutazione a livello di dominio scatta se più di una pagina su quattro fallisce. Questa soglia non l’ho trovata in nessuna delle pagine ufficiali che regolano il report. La Guida di Search Console descrive un’altra cosa: gli URL vengono raggruppati per esperienza utente simile e lo stato vale per il gruppo. Un raggruppamento non è una soglia di dominio.

Il FID è ancora un Core Web Vital. Il First Input Delay è uscito dai Core Web Vitals il 12 marzo 2024, giorno in cui Chrome ha dichiarato l’INP metrica stabile con l’annuncio del lancio, ed è uscito dagli strumenti il 10 settembre 2024. L’annuncio della fine del FID elenca otto superfici da cui è sparito, fra cui PageSpeed Insights nella sezione degli utenti reali, la CrUX API, BigQuery con la struct first_input fuori dallo schema a partire dal dataset 202409, e la libreria web-vitals con la rimozione di onFID nella versione 5.0. Una tabella di soglie con ancora una riga FID è di prima del 2024.

Quanti siti superano davvero i Core Web Vitals

Il 48% su mobile e il 56% su desktop, secondo il Web Almanac 2025 di HTTP Archive. Il dato che ancora circola in italiano, «solo un sito su cinque», è del 2022.

Su mobile la serie storica sale in modo regolare: 36% nel 2023, 44% nel 2024, 48% nel 2025. Su desktop si è quasi fermata: 48%, poi 55%, poi 56%. La crescita il capitolo la attribuisce anche a browser, dispositivi e reti migliori.

Senza l’unità di misura i numeri non si confrontano. Quel 48% e quel 56% contano i siti, cioè le origini: un sito, un voto. Altre figure dello stesso capitolo contano le pagine: le home page arrivano al 45% su mobile e al 47% su desktop, le pagine interne al 56% e al 61%. La home page è più lenta del resto del sito quasi ovunque, ed è quella che tutti misurano.

Domande frequenti

Le domande che tornano più spesso hanno la stessa radice: il report non mostra quello che ci si aspetta, e il motivo sta nella finestra di 28 giorni o nell’assenza di dati CrUX.

Il problema è di misurazione, prima che di ottimizzazione

Metà degli errori su questo argomento nascono dal guardare il numero sbagliato: il punteggio di laboratorio al posto del dato di campo, la media invece del 75° percentile, la singola URL quando il verdetto riguarda il gruppo. Chi parte dalla misura giusta scopre che il problema non era dove pensava, o che non c’era affatto perché il dato non esiste.

Il mio sito sta nel secondo caso, e non è una posizione comoda: quattro pagine su quattro con l’LCP di laboratorio sopra i 2,5 secondi restano quattro pagine da sistemare, con o senza CrUX a guardare.

Fai la stessa chiamata alla CrUX API sul tuo dominio. Se torna un 404 siamo nella stessa barca; se tornano dei numeri hai qualcosa che io non ho, e mi piacerebbe sapere in quali fasce cadono.

Per il resto della SEO tecnica: l’hub del cluster sta in SEO audit, i dati strutturati nella guida allo schema markup, e in indicizzazione Google come una pagina entra nell’indice.