Core Web Vitals

TL;DR — I Core Web Vitals sono tre punteggi che Google usa per misurare come una pagina sembra agli utenti reali: quanto velocemente si carica (LCP), quanto rapidamente risponde quando tocchi o fai clic (INP) e quanto si spostano gli elementi durante il caricamento (CLS). “Buono” significa LCP sotto 2,5 secondi, INP sotto 200 millisecondi e CLS sotto 0,1. Danno una piccola spinta al ranking, ma i contenuti validi contano molto di più.

Cosa sono i Core Web Vitals

Google vuole premiare le pagine piacevoli da usare, quindi ha ridotto la “buona esperienza di pagina” a tre elementi misurabili. Insieme formano i Core Web Vitals, spesso abbreviati in CWV:

• Largest Contentful Paint (LCP) — caricamento. Quanto tempo passa prima che compaia l’elemento più grande sullo schermo (di solito un’immagine hero o un titolo). Buono è ≤ 2,5 secondi.
• Interaction to Next Paint (INP) — reattività. Quando tocchi un pulsante o scrivi, quanto tempo passa prima che la pagina reagisca. Buono è ≤ 200 millisecondi.
• Cumulative Layout Shift (CLS) — stabilità visiva. Quanto si sposta la pagina durante il caricamento (per esempio una pubblicità spinge il testo verso il basso proprio mentre stai per toccarlo). Buono è ≤ 0,1.

Da dove arrivano i punteggi

I punteggi che Google usa davvero provengono da persone reali che visitano il tuo sito con Chrome, non da un test che esegui tu. Google raccoglie questi dati e giudica una pagina in base a ciò che ha sperimentato il 75 % dei visitatori. Quindi non puoi “passare” ottenendo un solo risultato veloce sul tuo computer: la maggior parte dei visitatori reali deve avere una buona esperienza. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Per questo un punteggio perfetto in uno strumento di speed testing non garantisce il superamento. Strumenti come PageSpeed Insights e Lighthouse eseguono un singolo test di laboratorio su un telefono simulato: sono ottimi per trovare problemi, ma non sono i numeri su cui Google basa il ranking.

Incidono sul ranking?

In parte. Google afferma che i Core Web Vitals sono usati dai suoi sistemi di ranking, ma non attribuisce loro alcun peso o percentuale ufficiale ed è esplicito sul fatto che contenuti pertinenti possano comunque superare una pagina con un’esperienza mediocre. Se i contenuti non sono pertinenti, velocità e stabilità non bastano. Come ha detto John Mueller di Google, “it’s not going to make your site’s rankings jump up.” (traduzione) «non farà schizzare in alto il posizionamento del tuo sito».

La mia valutazione sincera dopo anni di lavoro è che la maggior parte dei siti non vedrà un grande vantaggio di ranking inseguendo questi numeri. Ma rendere il sito più veloce e stabile non ha nulla di sbagliato: i visitatori lo notano e aiuta le conversioni anche quando il ranking non cambia.

Un errore comune

Attenzione al vecchio nome: potresti vedere ancora citato FID (First Input Delay) come Core Web Vital. Non lo è più: INP ha sostituito FID il 12 marzo 2024. Se uno strumento o un articolo ti dice ancora di ottimizzare FID, è obsoleto.

Vuoi la versione più approfondita — soglie esatte, dati di campo contro dati di laboratorio, il loro peso reale sul ranking e quale strumento usare nei vari casi? Passa alla scheda Avanzato.

TL;DR — I Core Web Vitals sono tre metriche UX misurate sul campo: LCP (caricamento, “buono” ≤ 2,5 s), INP (reattività, ≤ 200 ms) e CLS (stabilità visiva, ≤ 0,1), giudicate ciascuna al 75° percentile degli utenti Chrome reali (CrUX) su una finestra mobile di 28 giorni. Le soglie sono uguali per mobile e desktop, ma Google valuta ciascuna classe separatamente e si aspetta che tutte e tre le metriche siano buone, non solo una. INP ha sostituito FID il 12 marzo 2024. Google dice che i suoi sistemi di ranking usano i Core Web Vitals, ma non esiste un peso ufficiale né una percentuale da “spareggio”: un buon punteggio non garantisce ranking migliori e la pertinenza può comunque prevalere. I punteggi di laboratorio (Lighthouse/PSI) sono misurazioni diagnostiche e spesso non coincidono con i dati sul campo. TTFB e FCP sono “altri Web Vitals” diagnostici; TBT e Speed Index sono proxy di laboratorio.

Cosa conta come Core Web Vital

Google definisce i Core Web Vitals come “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traduzione) «il sottoinsieme dei Web Vitals che si applica a tutte le pagine web, dovrebbe essere misurato da tutti i proprietari di siti e sarà mostrato in tutti gli strumenti Google». Sono esattamente tre e ciascuno misura una dimensione diversa dell’esperienza percepita su una pagina:

Google valuta le tre soglie “buone” al 75° percentile: LCP a 2,5 secondi, INP a 200 millisecondi e CLS a 0,1. Una pagina viene giudicata complessivamente “buona” solo quando tutte e tre superano la propria soglia a p75, non solo una o due. Le soglie sono uguali per mobile e desktop, anche se Google valuta e riporta separatamente ogni classe di dispositivo. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Tutto il resto di ciò che hai sentito — TTFB, FCP, TBT, Speed Index — non è un Core Web Vital. Ne parleremo sotto.

LCP — caricamento

LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (traduzione) «indica il tempo di rendering dell’immagine, del blocco di testo o del video più grande visibile nel viewport, calcolato dal momento in cui l’utente ha aperto la pagina». In pratica, l’elemento LCP è in genere un’immagine hero, una grande immagine di sfondo o il blocco del titolo. Si tratta dell’elemento visibile più grande: viewport di dimensioni diverse possono avere elementi LCP diversi, ed è uno dei motivi per cui i dati sul campo e quelli di laboratorio divergono.

INP — reattività

INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traduzione) «valuta la reattività complessiva di una pagina alle interazioni osservando la latenza di tutti i clic, tocchi e input da tastiera durante l’intera visita dell’utente». Misura l’interazione completa: ritardo dell’input → elaborazione del gestore dell’evento → tempo necessario per visualizzare il frame successivo.

Questo è il grande miglioramento rispetto alla metrica sostituita. INP osserva tutte le interazioni, non solo la prima: FID misurava il ritardo dell’input della primissima interazione. INP è diventato un Core Web Vital il 12 marzo 2024, sostituendo First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch Quel giorno FID è stato rimosso da Search Console. È completamente ritirato: non ottimizzarlo.

Una sfumatura da ricordare: INP non è la tua singola interazione peggiore, ma un percentile alto di tutte le interazioni. Un solo clic scattoso non farà crollare una pagina altrimenti valida.

CLS — stabilità visiva

CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traduzione) «misura il maggiore gruppo di punteggi di spostamento del layout prodotto dagli spostamenti imprevisti durante l’intero ciclo di vita di una pagina». Il “gruppo”, cioè la finestra di sessione, riunisce gli spostamenti che avvengono entro 1 secondo l’uno dall’altro, fino a una finestra complessiva di 5 secondi. Tra le cause comuni Google cita “images or videos with unknown dimensions,” (traduzione) «immagini o video con dimensioni sconosciute», “fonts that render larger or smaller than its initial fallback,” (traduzione) «font visualizzati più grandi o più piccoli rispetto al fallback iniziale» e “third-party ads or widgets that dynamically resize themselves.” (traduzione) «annunci o widget di terze parti che cambiano dinamicamente dimensione».

Dati di campo contro dati di laboratorio — misurazione e diagnosi

Questa è la distinzione che genera più confusione, quindi sii preciso:

• I dati sul campo (CrUX) sono “data collected from the real users visiting your site.” (traduzione) «dati raccolti dagli utenti reali che visitano il sito». Vengono riportati al 75° percentile su una finestra mobile di 28 giorni, con segmenti separati per dispositivi mobili e desktop. I Core Web Vitals rappresentano questa esperienza reale e sono usati dai sistemi di ranking di Google. Riflettono dispositivi, reti, stati della cache e cache back/forward reali.
• I dati di laboratorio sono “data collected in a controlled environment with predefined device and network settings” (traduzione) «dati raccolti in un ambiente controllato con impostazioni predefinite per dispositivo e rete»: un singolo telefono emulato, cache fredda e nessun utente reale. Li producono Lighthouse e la sezione di laboratorio di PageSpeed Insights. Sono uno strumento diagnostico per individuare problemi, non una misurazione sul campo. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

La stessa guida di Google afferma: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traduzione) «se per una pagina sono disponibili sia dati sul campo sia dati di laboratorio, bisogna usare i dati sul campo per stabilire le priorità». Inoltre, il Performance Score di Lighthouse “often does not correlate with field Core Web Vitals.” (traduzione) «spesso non è correlato ai Core Web Vitals sul campo». Dico la stessa cosa nella mia guida ai Core Web Vitals: i dati di laboratorio sono più utili per testare e iterare, perché i dati CWV sul campo usano una media mobile di 28 giorni; la correzione non sarà visibile per settimane.

La regola p75 e perché conta

Una pagina supera il test solo se il 75 % degli utenti reali raggiunge la soglia “buona”. È una soglia volutamente indulgente ma reale: la maggior parte dei visitatori (3 su 4) ha avuto una buona esperienza, senza però lasciare che pochi valori anomali su connessioni pessime dominino il risultato. È anche per questo che un caricamento di 1,8 s sul tuo telefono non significa nulla da solo: conta il tuo p75 sull’intera popolazione.

Livello pagina contro livello origine — non farti ingannare

Molti strumenti mostrano per impostazione predefinita un punteggio a livello di origine (media dell’intero sito), che può essere molto più roseo delle singole pagine. Nel mio studio sui dati CWV (CrUX più 5,2 milioni di pagine da Ahrefs Site Audit), solo il 21,2 % delle pagine singole superava tutte e tre le soglie, contro il 33 % a livello di origine. La documentazione Google sulla page experience dice che i suoi sistemi valutano generalmente le pagine singolarmente, anche se esegue anche valutazioni più ampie dell’intero sito: quindi un’origine che “passa” può nascondere molte pagine singole non riuscite. Quando uno strumento offre entrambe le viste, non presumere che la media a livello di origine ti dica cosa sta facendo una pagina specifica: controlla anche il dato a livello di pagina.

Un altro problema è che le pagine senza traffico sufficiente non hanno alcun dato di campo CrUX e CrUX include solo utenti Chrome che hanno accettato di condividere le statistiche di utilizzo (non Chrome su iOS né altri browser). È una lacuna di idoneità dei dati, non un fallimento: dati di campo mancanti non equivalgono a un punteggio scarso. Il modo in cui ogni strumento raggruppa pagine simili o gestisce gli URL con poco traffico (PSI, Search Console, API CrUX) è documentato da quel prodotto specifico, non da una regola universale unica.

Quanto contano davvero i Core Web Vitals per il ranking?

Sono un segnale di ranking confermato: Google dice che i suoi sistemi di ranking usano i Core Web Vitals. Ciò che la documentazione attuale di Google non fa è assegnare a quel segnale un peso, una percentuale o l’etichetta “spareggio” ufficiale; fai quindi attenzione a ripetere queste formule come se fossero parole di Google.

Sul versante “è un segnale reale”, la documentazione Google afferma che i Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (traduzione) «insieme ad altri aspetti dell’esperienza sulla pagina, sono coerenti con ciò che i nostri sistemi principali di ranking cercano di premiare»; John Mueller ha inoltre dichiarato che sono “more than a tie-breaker, but it also doesn’t replace relevance.” (traduzione) «più di un criterio di spareggio, ma non sostituiscono la pertinenza».

Sul versante “non esagerare”, Mueller ha anche detto che “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (traduzione) «i Core Web Vitals non sono fattori enormi nel ranking e dubito che si possa osservare un forte calo solo per questo»; nell’aggiornamento della documentazione di marzo 2024 ha aggiunto via LinkedIn che “it’s not going to make your site’s rankings jump up.” (traduzione) «non farà schizzare in alto il posizionamento del tuo sito». La documentazione Google sull’esperienza della pagina è esplicita: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traduzione) «Google Search cerca sempre di mostrare i contenuti più pertinenti, anche quando l’esperienza sulla pagina è mediocre». La documentazione del 2024 avverte inoltre che “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (traduzione) «cercare di ottenere un punteggio perfetto solo per motivi SEO potrebbe non essere il modo migliore di impiegare il proprio tempo».

La mia lettura pragmatica è che la pertinenza domina, Google non ha indicato quanto pesino i CWV e la maggior parte dei siti non vedrà un grande beneficio lavorando su di essi per il ranking. Detto questo, i miglioramenti UX sottostanti valgono la pena per utenti e conversioni, e le piattaforme (WordPress, Cloudflare, framework) assorbono sempre più automaticamente il carico dell’ottimizzazione. Soprattutto per piccole attività e imprese locali, di solito non dovrebbe essere in cima alla lista.

Un’ulteriore precisazione dell’aggiornamento 2024: tra i segnali più ampi di page experience, solo i Core Web Vitals sono confermati come contributo diretto al ranking. HTTPS, compatibilità mobile, assenza di interstitial invasivi e chiarezza dei contenuti sono tutte buone pratiche, ma non aumentano direttamente il ranking come un tempo lasciavano intendere i documenti.

Gli “altri Web Vitals” — diagnostici, non Core

Sono citati continuamente e spesso classificati male. Nessuno di questi è un Core Web Vital:

• Time to First Byte (TTFB) — tempo che intercorre prima dell’arrivo del primo byte della risposta. “precedes every other meaningful loading performance metric” (traduzione) «precede ogni altra metrica significativa delle prestazioni di caricamento» e contribuisce a LCP, ma Google precisa: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (traduzione) «poiché TTFB non è una metrica Core Web Vitals, non è indispensabile che i siti rispettino la soglia TTFB “buona”». (Buono ≤ 0,8 s.) Metrica diagnostica.
• First Contentful Paint (FCP) — tempo necessario prima che venga visualizzato un contenuto qualsiasi. È una diagnostica utile del caricamento (buono ≤ 1,8 s), ma non è una metrica Core.
• Total Blocking Time (TBT) — un proxy di laboratorio per INP. Strumenti come Lighthouse “cannot measure INP” (traduzione) «non possono misurare INP» senza un utente reale e riportano quindi TBT. Solo laboratorio.
• Speed Index — proxy di laboratorio della velocità di caricamento percepita. Solo Lighthouse.

Usali per fare debug. Non riportarli come Core Web Vitals e non trattare le loro soglie come gate di ranking.

Un mito da abbandonare

Potresti vedere “Engagement Reliability” presentata come un nuovo Core Web Vital. Non esiste alcun annuncio ufficiale di Google per questa metrica: circola solo in contenuti di terze parti. I Core Web Vitals sono LCP, INP e CLS. Finché Google non dirà diversamente, l’elenco è questo.

Come misurare — e quale strumento usare

Abbina lo strumento al lavoro:

• Rilevante per il ranking (dati di campo): PageSpeed Insights (mostra i dati di campo CrUX a livello di pagina e origine), il report Core Web Vitals di Google Search Console (raggruppa pagine simili e mostra pattern dell’intero sito), API CrUX / BigQuery (analisi personalizzata e per paese) e la libreria JS web-vitals (per raccogliere il tuo RUM).
• Debug (dati di laboratorio): Lighthouse, pannello Performance di Chrome DevTools e sezione laboratorio di PSI. Trovano la causa, ma non decidono il tuo ranking.

Il workflow che suggerisco è: usa GSC per trovare quali gruppi di pagine falliscono sul campo, conferma con PageSpeed Insights a livello di pagina, poi passa a Lighthouse / DevTools per diagnosticare e iterare, sapendo che i numeri di campo possono impiegare fino a 28 giorni per aggiornarsi.

Dove andare dopo: il cluster delle prestazioni web

Questo hub è la mappa. Ogni argomento sotto è un approfondimento autonomo.

I tre Core Web Vitals

• Largest Contentful Paint — la metrica di caricamento: cosa conta come elemento LCP, il target ≤2,5 s e come farlo comparire prima.
• Interaction to Next Paint — la metrica di reattività che ha sostituito FID: ritardo dell’input, elaborazione dell’evento e ritardo di presentazione, e come ridurli.
• Cumulative Layout Shift — la metrica di stabilità visiva: finestre di sessione, cause usuali (media dimensionati, font, annunci iniettati) e come raggiungere ≤0,1.

Metriche di supporto e diagnostiche

• Time to First Byte — latenza del server/risposta che alimenta LCP; utile per il debug, non è un Core Web Vital.
• First Contentful Paint — quando viene dipinto il primo contenuto; diagnostico del caricamento.
• Total Blocking Time — il proxy di laboratorio che Lighthouse usa per approssimare INP.
• Speed Index — il proxy di laboratorio della velocità di caricamento percepita.

Come vengono misurate

• PageSpeed Insights — dati di campo (CrUX) più un report di laboratorio Lighthouse in un unico posto.
• Google Lighthouse — il motore di laboratorio/diagnostico dietro PSI e DevTools.
• Chrome UX Report (CrUX) — il dataset degli utenti reali su cui si basa la valutazione di Google.

Per l’intero cluster, vedi l’hub Web Performance. Ogni articolo affine rimanda qui automaticamente quando viene pubblicato.

Riepilogo AI

Una sintesi della versione Avanzata:

• Core Web Vitals = tre metriche di campo: LCP (caricamento, buono ≤ 2,5 s), INP (reattività, ≤ 200 ms) e CLS (stabilità visiva, ≤ 0,1). Tutto il resto (TTFB, FCP, TBT, Speed Index) non è Core.
• Giudicati sui dati di campo: utenti Chrome reali tramite CrUX, al 75° percentile, su una finestra mobile di 28 giorni. Le soglie sono uguali per mobile e desktop ma valutate separatamente e Google si aspetta che tutte e tre le metriche siano buone, non solo una.
• INP ha sostituito FID il 12 marzo 2024. FID è completamente ritirato; INP misura tutte le interazioni, non solo la prima.
• Gli strumenti di laboratorio (Lighthouse/PSI) sono diagnostici, non misurazioni di campo e spesso non corrispondono ai CWV di campo. Usali per trovare le cause; i numeri di campo hanno un ritardo fino a 28 giorni.
• Il livello pagina contro il livello origine conta: passa circa il 21,2 % delle pagine contro circa il 33 % delle origini (il mio studio CWV). Google usa il livello pagina: le medie dell’origine nascondono pagine non riuscite.
• Peso sul ranking: usati, ma senza peso assegnato. Google dice che i suoi sistemi di ranking usano i Core Web Vitals senza una percentuale ufficiale o un’etichetta “spareggio”; la pertinenza domina e un buon punteggio non garantisce il ranking. Mueller: “not giant factors in ranking.” Solo i CWV (non HTTPS, compatibilità mobile o interstitial) contribuiscono direttamente secondo la documentazione 2024.
• Mito da ignorare: “Engagement Reliability” non è un Core Web Vital confermato.
• Strumenti: dati di campo = PSI, report CWV di GSC, API CrUX, web-vitals.js; debug = Lighthouse, DevTools, sezione laboratorio di PSI.

Documentazione ufficiale

Documentazione primaria di Google.

web.dev (team Chrome)

• Web Vitals — l’iniziativa, le tre metriche, la regola p75 e il motivo per cui TTFB/FCP sono “altri” Web Vitals.
• Largest Contentful Paint (LCP) — definizione, soglie ed elementi LCP idonei.
• Interaction to Next Paint (INP) — definizione, soglie e scomposizione ritardo input → elaborazione → presentazione.
• Cumulative Layout Shift (CLS) — definizione, finestre di sessione e cause comuni.
• Definire le soglie delle metriche Core Web Vitals — perché sono state scelte ogni soglia “buona” e il 75° percentile.
• Differenze tra dati di laboratorio e di campo — perché i numeri di campo (CrUX) e di laboratorio (Lighthouse) divergono.
• Workflow/strumenti Core Web Vitals — quale strumento riporta dati di campo e di laboratorio.
• INP passa ai Core Web Vitals (maggio 2023) — l’annuncio che INP avrebbe sostituito FID.
• Interaction to Next Paint è ufficialmente un Core Web Vital (12 marzo 2024) — la conferma del lancio.
• TTFB e FCP — gli “altri Web Vitals” diagnostici.

Google Search Central

• Capire i Core Web Vitals e i risultati di Google Search — relazione tra CWV e ranking.
• Capire la page experience nei risultati di Google Search — il quadro più ampio della page experience e l’idea che “la pertinenza vince”.
• INP entra nei Core Web Vitals (maggio 2023) — l’annuncio di Search Central.

Documentazione per sviluppatori Chrome

• Chrome User Experience Report (CrUX) — insieme di dati sugli utenti reali, requisiti di idoneità e finestra di 28 giorni.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google. Ogni link è un deep link che porta al passaggio citato nella pagina sorgente.

Google — cosa sono i Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traduzione) «I Core Web Vitals sono il sottoinsieme dei Web Vitals applicabile a tutte le pagine web, che tutti i proprietari di siti dovrebbero misurare e che sarà mostrato in tutti gli strumenti Google». — Philip Walton, web.dev. Vai alla citazione
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (traduzione) «LCP indica il tempo di rendering dell’immagine, del blocco di testo o del video più grande visibile nel viewport, calcolato dal momento in cui l’utente ha aperto la pagina». — web.dev (LCP). Vai alla citazione
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traduzione) «INP è una metrica che valuta la reattività complessiva di una pagina osservando la latenza di tutti i clic, tocchi e input da tastiera durante l’intera visita dell’utente». — web.dev (INP). Vai alla citazione
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traduzione) «CLS misura il maggiore gruppo di punteggi di spostamento del layout prodotto dagli spostamenti imprevisti durante l’intero ciclo di vita di una pagina». — web.dev (CLS). Vai alla citazione

Google — INP sostituisce FID

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” — Rick Viscomi, web.dev (12 marzo 2024). Vai alla citazione

Google — dati di campo contro laboratorio e ranking

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traduzione) «Se per una pagina sono disponibili sia dati sul campo sia dati di laboratorio, bisogna usare i dati sul campo per stabilire le priorità». — Philip Walton, web.dev. Vai alla citazione
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traduzione) «Il Chrome User Experience Report, noto anche come Chrome UX Report o CrUX, è un insieme di dati che riflette l’esperienza degli utenti Chrome reali sulle destinazioni più frequentate del web». — Chrome for Developers (documentazione CrUX). Vai alla citazione

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (traduzione) «È un fattore di ranking ed è più di un criterio di spareggio, ma non sostituisce la pertinenza». — tramite Search Engine Journal (Reddit, agosto 2021). Leggi la copertura
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (traduzione) «I Core Web Vitals non sono fattori enormi nel ranking e dubito che si possa osservare un forte calo solo per questo». — tramite Stan Ventures (2024). Leggi la copertura

Checklist Core Web Vitals

Un controllo rapido per confermare che stai misurando la cosa giusta e correggendo le pagine giuste:

• Stai leggendo i dati di campo (CrUX), non solo un punteggio di laboratorio, per le metriche su cui Google basa il ranking.
• Guardi i numeri a livello di pagina, non solo la media a livello di origine.
• Sono controllati tutti e tre: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 a p75.
• Mobile e desktop sono esaminati separatamente (Google valuta ciascuno).
• Non stai ottimizzando FID: è stato ritirato il 12 marzo 2024 (usa INP).
• Il report Core Web Vitals di GSC è stato esaminato per i gruppi di pagine non riusciti, non per singoli casi.
• Sai che le pagine con poco traffico possono non avere alcun dato di campo CrUX.
• Gli strumenti di laboratorio (Lighthouse/PSI) sono usati per la diagnosi, non come gate pass/fail, e non stai aspettando un Performance Score perfetto.
• Concedi fino a 28 giorni perché le correzioni di campo compaiano.
• Non insegui i CWV prima della pertinenza dei contenuti e di vantaggi SEO più grandi.

I modelli mentali

1. Tre dimensioni, tre metriche. LCP = caricamento, INP = reattività, CLS = stabilità visiva. Se sai in quale dimensione vive un problema, sai quale metrica (e quale approfondimento) aprire.

2. Il campo serve al ranking; il laboratorio serve a correggere. Google basa il ranking sui dati di campo CrUX a p75 su 28 giorni. I punteggi di laboratorio Lighthouse/PSI trovano le cause. Non trattare mai un punteggio di laboratorio come il tuo numero di ranking: spesso non correla nemmeno.

3. Il livello pagina batte il livello origine. Un’origine che “passa” può nascondere pagine non riuscite. Google usa i dati a livello di pagina quando li ha. Quando uno strumento mostra entrambe le viste, fidati di quella a livello pagina.

4. Usati, ma senza peso assegnato. I CWV sono un segnale di ranking confermato a cui Google non ha mai associato un peso ufficiale: la pertinenza può comunque prevalere. Correggi i CWV per utenti e conversioni, non aspettarti un salto nel ranking.

5. Il test “è davvero Core?”. Solo LCP, INP e CLS sono Core Web Vitals. TTFB e FCP sono diagnostici; TBT e Speed Index sono proxy di laboratorio. “Engagement Reliability” non è affatto confermato.

Core Web Vitals — scheda rapida

I tre Core Web Vitals (dati di campo, p75)

Metriche diagnostiche — NON Core Web Vitals

Fatti rapidi

• Valutazione = dati di campo CrUX, 75° percentile, finestra mobile di 28 giorni, mobile e desktop separati.
• INP ha sostituito FID il 12 marzo 2024. FID è completamente ritirato.
• I punteggi di laboratorio (Lighthouse/PSI) sono diagnostici, non misurazioni di campo e spesso non corrispondono ai CWV di campo.
• È il livello pagina quello usato da Google; le medie a livello origine possono ingannare (circa 21,2 % delle pagine supera il test contro circa il 33 % delle origini nel mio studio CWV).
• Peso sul ranking: usati dai sistemi di ranking Google, senza peso ufficiale dichiarato; la pertinenza domina e un buon punteggio non garantisce nulla.
• “Engagement Reliability” non è un Core Web Vital confermato.

Quale Core Web Vital dovrei analizzare per primo?

I Core Web Vitals peggiorano dopo una release

1. Conferma il segnale. Separa campo da laboratorio, URL da origine e mobile da desktop. Se è cambiata una sola esecuzione di laboratorio, riproducila prima di dichiarare un incidente.
2. Identifica il vital che fallisce. LCP, INP e CLS rappresentano problemi diversi. Se si sono mossi più valori, controlla prima le modifiche condivise della release e gli script di terze parti.
3. Collega la regressione a un deployment. Confronta tracce RUM o di laboratorio ripetibili prima e dopo la release. Se la tempistica non coincide, esamina il mix di traffico e dispositivi.
4. Diagnostica la metrica, non il punteggio. Per LCP analizza elemento e sotto-parti; per INP le interazioni lente e il lavoro sul main thread; per CLS le sorgenti degli spostamenti.
5. Pubblica la correzione più piccola attribuibile. Validala subito in laboratorio. Se rompe una funzionalità o peggiora un altro vital, fai rollback.
6. Osserva gli utenti reali. Usa RUM per il segnale anticipatore e CrUX/Search Console per il verdetto di campo mobile. Documenta ambito e finestra, così gli stakeholder non si aspettano un reset CrUX nello stesso giorno.

Errori Core Web Vitals che fanno sprecare lavoro

Ottimizzare il punteggio Lighthouse composito

La valutazione di campo di Google usa LCP, INP e CLS da dati di utenti reali, non il singolo numero Performance di Lighthouse. Diagnostica la metrica di campo che fallisce e usa Lighthouse come un ambiente di debug controllato.

Trattare i Core Web Vitals come scorciatoia per il ranking

I CWV sono un segnale di page experience a cui Google non ha mai assegnato un peso ufficiale; la pertinenza continua a dominare. Correggi una cattiva esperienza per gli utenti, ma non promettere un salto di ranking né sostituire senza evidenze lavoro più importante su contenuti e indicizzazione.

Mescolare valori URL, origine, mobile e desktop

Ambiti diversi possono raccontare storie diverse. Etichetta ogni valore e non dichiarare che una pagina supera il test perché un fallback dell’origine o un aggregato desktop è verde.

Aspettare CrUX prima di controllare una release

La finestra mobile di 28 giorni è troppo lenta per la QA del deployment. Valida subito il meccanismo in laboratorio e con RUM, poi usa CrUX per confermare l’esito di campo più lungo.

Strumenti per misurare i Core Web Vitals

Controlla con Core Web Vitals History & Competitor Comparison:

1. Aggiungi un sito (un’origine nuda come example.com ha più dati CrUX; aggiungine fino a 5 per il confronto).
2. Scegli mobile o desktop, poi esegui il confronto.
3. Leggi la scheda di oggi per il superamento/fallimento di LCP, INP e CLS, poi il grafico settimanale per vedere se ogni metrica si sta avvicinando alla fascia buona o se ne sta allontanando.

Dati di campo — misurazione dei Core Web Vitals da utenti reali

• PageSpeed Insights — dati di campo CrUX a livello pagina e origine, più un report di laboratorio Lighthouse accanto.
• Google Search Console — report Core Web Vitals — raggruppa pagine simili e mostra pattern di campo dell’intero sito; è il modo più rapido per trovare i gruppi di pagine che falliscono.
• API CrUX / BigQuery — analisi personalizzata e per paese direttamente dal dataset sorgente.
• Libreria JavaScript web-vitals — raccogli i tuoi dati da utenti reali (RUM), per esempio inviandoli ad analytics.

Dati di laboratorio — per il debug (non per il ranking)

• Lighthouse — opportunità diagnostiche e Performance Score (non di ranking).
• Pannello Performance di Chrome DevTools — debug a livello di trace di LCP, spostamenti del layout e task lunghi.
• Sezione laboratorio di PageSpeed Insights — raccomandazioni basate su Lighthouse sotto i dati di campo.

Regola pratica: GSC per trovare dove fallisci sul campo → PSI per confermare a livello pagina → Lighthouse / DevTools per diagnosticare e iterare.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Core Web Vitals: How to Improve Them (Ahrefs) — la mia guida pratica completa alle tre metriche e a cosa correggere.
• Core Web Vitals Data Study (Ahrefs) — CrUX più 5,2 milioni di pagine; il risultato sui tassi di superamento a livello pagina contro origine.
• Guida a Largest Contentful Paint (LCP) (Ahrefs).
• Guida a Cumulative Layout Shift (CLS) (Ahrefs).
• Guida a PageSpeed Insights (Ahrefs).
• The Beginner’s Guide to Technical SEO — dove si colloca la page experience nel quadro più ampio.

Ufficiale

• web.dev — Web Vitals e gli articoli sulle singole metriche collegati nella sezione Documentazione ufficiale.
• Google aggiorna la documentazione sulla page experience per chiarire i segnali di ranking (Search Engine Land) — Barry Schwartz sul cambiamento documentale di marzo 2024.

Dal settore

• Fattore di ranking Core Web Vitals: più di un criterio di spareggio (Search Engine Journal) — copertura della dichiarazione di John Mueller su Reddit secondo cui i CWV sono “more than a tie-breaker” (traduzione) «più di un criterio di spareggio», ma non sostituiscono la pertinenza.
• Priorità dei Core Web Vitals per piccole attività e imprese locali (Search Engine Roundtable) — commento di Mueller su Mastodon secondo cui il lavoro sui CWV non dovrebbe essere la priorità principale per queste attività.
• Confermato: i Core Web Vitals non sono un grande fattore di ranking (Stan Ventures) — la frase di Mueller “not giant factors in ranking” (traduzione) «non sono fattori enormi nel ranking» nel suo contesto.
• Impatto dei Core Web Vitals sulla SEO (RUMvision) — aggiornato a novembre 2025; riepilogo approfondito in forma di FAQ delle dichiarazioni dei portavoce e delle sfumature del segnale di ranking.
• Aggiornamento Page Experience di Google: criterio di spareggio (Search Engine Roundtable) — prima formulazione di Mueller e Illyes sullo spareggio, precedente al lancio dell’aggiornamento.

Statistiche degne di citazione

• Solo circa il 21,2 % delle pagine singole supera tutti e tre i Core Web Vitals, contro circa il 33 % a livello di origine, secondo il mio studio sui dati CWV (CrUX più 5,2 milioni di pagine da Ahrefs Site Audit). I sistemi Google valutano generalmente le pagine singolarmente, quindi una media rosea dell’origine può comunque nascondere molte pagine non riuscite. Fonte
• I siti faticano soprattutto con LCP. Lo studio ha trovato progressi sui vecchi FID e sul CLS, ma ritardi su LCP; “almost no sites on 3G or slower connections are passing.” Fonte
• Le soglie “buone”: LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1, ciascuna al 75° percentile dei dati di campo: i target Core Web Vitals documentati da Google. Fonte
• INP ha sostituito FID il 12 marzo 2024, data in cui FID ha smesso di essere un Core Web Vital ed è stato rimosso da Search Console. Fonte

Mettiti alla prova: Core Web Vitals

Cinque domande rapide sui Core Web Vitals. Scegli una risposta per ciascuna, poi controlla.

Dimostra che una correzione LCP/INP/CLS è arrivata davvero

La trappola di una correzione delle prestazioni è festeggiare il punteggio di laboratorio il giorno della pubblicazione. Il laboratorio (Lighthouse) ti dice se la modifica può funzionare; solo i dati di campo (CrUX) dicono se ha funzionato per utenti reali e si muovono con un ritardo mobile di 28 giorni. Esegui entrambi, in quest’ordine.

Test 1 — La correzione ha migliorato la metrica di laboratorio

• Test da eseguire — Esegui la pagina tramite il Core Web Vitals Checker (o Lighthouse / PageSpeed Insights) prima e dopo la modifica.
• Risultato previsto — La metrica di laboratorio scelta si muove nella direzione corretta: per esempio l’elemento LCP viene renderizzato prima, non compaiono nuovi spostamenti del layout e il diagnostico specifico che stavi correggendo passa.
• Interpretazione del fallimento — Nessun movimento in laboratorio significa che la modifica non ha toccato il percorso critico (hai ottimizzato un elemento che non era l’elemento LCP o uno script che non bloccava).
• Finestra di monitoraggio — Immediata: i test di laboratorio vengono eseguiti su richiesta.
• Trigger di rollback — Una regressione in un’altra metrica (hai corretto LCP ma introdotto CLS o aggiunto JavaScript che peggiora INP): il laboratorio la rileva prima degli utenti reali.

Test 2 — Gli utenti reali lo percepiscono davvero (dati di campo)

• Test da eseguire — Monitora in CrUX il p75 di LCP, INP e CLS della pagina o dell’origine tramite Core Web Vitals History & Competitor Comparison oppure il report Core Web Vitals di GSC.
• Risultato previsto — Il p75 della metrica corretta entra nella fascia “Buono” e vi rimane (soglie Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1).
• Interpretazione del fallimento — Il laboratorio migliora ma i dati sul campo no: la correzione ha favorito un test su connessione veloce, non il mix reale di dispositivi e reti, oppure non è condivisa da un numero sufficiente di URL del gruppo.
• Finestra di monitoraggio — 28 giorni mobili: CrUX usa una finestra retrospettiva di 28 giorni, quindi servono circa quattro settimane di dati accumulati prima che il p75 sia affidabile. Non trarre conclusioni nella prima settimana.
• Trigger di rollback — Il p75 supera di nuovo la soglia “scarso” oppure il numero di URL “Buoni” in GSC diminuisce dopo una modifica al template: è un forte segnale che il rilascio ha peggiorato le prestazioni degli utenti reali.

Il KPI permanente di questo argomento

Separato dalla validazione di una singola correzione, questo è ciò che osservi trimestre dopo trimestre per sapere se la page experience è sana. Qui esiste un benchmark difendibile: Google pubblica le soglie, quindi non inventiamo numeri.

p75 di LCP, INP e CLS (dati di campo)

• Metrica — Il valore al 75° percentile di ogni Core Web Vital nelle visite reali, per gruppo di pagine e dispositivo.
• Cosa indica — Se il 75 % degli utenti reali riceve una buona esperienza: è la soglia esatta usata da Google per classificare un URL come idoneo. Conta il p75, non la media, perché rappresenta la coda più lenta.
• Come recuperarlo — CrUX tramite Core Web Vitals History & Competitor Comparison, il report Core Web Vitals di GSC — dati sul campo raggruppati per pattern di URL — oppure PageSpeed Insights per un singolo URL.
• Benchmark / intervallo realistico — Soglie Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1 per “Buono”; le fasce “Da migliorare” / “Scarso” sono 2,5–4 s / >4 s, 200–500ms / >500ms e 0,1–0,25 / >0,25. Sono le soglie pubblicate, non un obiettivo inventato.
• Cadenza — Finestra mobile di 28 giorni, quindi revisione mensile: un controllo quotidiano rilegge la stessa finestra retrospettiva. Considera i punteggi di laboratorio indicatori anticipatori e il p75 CrUX un indicatore ritardato.

Copertura degli URL “Buoni” nel sito

• Metrica — La quota degli URL indicizzati nella fascia “Buono” del report Core Web Vitals di GSC (mobile e desktop monitorati separatamente).
• Cosa indica — Quanto si sono propagate le correzioni: una singola pagina veloce non sposta il sito, mentre i miglioramenti a livello di template sì.
• Come recuperarlo — GSC → report Core Web Vitals → conteggio nel tempo degli URL Buoni / Da migliorare / Scarsi.
• Benchmark / intervallo realistico — Situazionale: dipende dai template e dal mix di traffico, quindi stabilisci la tua baseline e aumenta nel tempo la quota Buona invece di inseguire una percentuale inventata.
• Cadenza — Mensile, oppure settimanale subito dopo una modifica a template/theme mentre la finestra di campo si aggiorna.

Cronologia modifiche