Novità sui Core Web Vitals: cosa è cambiato e cosa sistemare per primo
Di Toy Wen Da, Co-founder · Aggiornato · 12 min di lettura
Tradotto dall'originale in inglese. Leggilo in inglese
Se stai cercando novità sui core web vitals, probabilmente hai visto una segnalazione in Search Console o hai sentito parlare di un cambio di metrica. La risposta breve è che Interaction to Next Paint (INP) ha sostituito First Input Delay (FID) come metrica ufficiale dei Core Web Vitals il 12 marzo 2024. Apri il report Core Web Vitals in Search Console per vedere quali URL sono segnalati.
Prima di toccare qualsiasi codice, passa la pagina nel Website Speed Test gratuito. Recupera i punteggi di Lighthouse e indica quale metrica sta penalizzando la pagina. Saprai se il problema riguarda il caricamento, l'interazione o il layout prima ancora di aprire una sola riga di codice.
Cosa è cambiato di recente nei Core Web Vitals
Le novità sui Core Web Vitals arrivano di solito in due forme: un cambio di metrica, oppure una fuga di notizie che conferma quanto Google si affidi al comportamento reale degli utenti dietro le quinte. Entrambe sono avvenute nel 2024, ed entrambe influenzano ancora oggi le priorità dei team nelle correzioni.
Il passaggio da FID a INP
Fino al 12 marzo 2024, Google misurava la reattività delle pagine con First Input Delay, o FID. Considerava solo la prima interazione di un visitatore con la pagina, che fosse un clic, un tocco o la pressione di un tasto, quindi una pagina poteva superare FID senza problemi e risultare comunque lenta a ogni interazione successiva.
INP colma questa lacuna osservando ogni clic, tocco e pressione di tasto durante l'intera visita, poi riporta l'interazione più lenta che non fosse un caso isolato anomalo. I dati d'uso di Chrome indicano che circa il 90% del tempo che un visitatore trascorre su una pagina avviene dopo il termine del caricamento. FID misurava una porzione minima dell'esperienza, mentre INP misura la parte che gli utenti percepiscono davvero.
Un buon punteggio INP è di 200 millisecondi o meno. Tra 200 e 500 millisecondi è considerato "Needs improvement" (da migliorare), e oltre i 500 millisecondi Search Console lo segna come "Poor" (scarso).
La fuga di notizie sulla Content Warehouse API
A marzo 2024 è emerso pubblicamente un insieme di documentazione interna delle API di Google, e i commentatori del settore hanno passato gran parte del 2025 ad analizzarla. Non ha riscritto le regole dei Core Web Vitals, ma ha confermato qualcosa che molti SEO già sospettavano: le metriche pubbliche sono un indicatore indiretto di un sistema di ranking molto più ampio, basato sui clic.
La documentazione trapelata cita moduli legati ai dati d'uso di Chrome e un sistema chiamato NavBoost, che riordina i risultati usando circa 13 mesi di comportamento di clic continuativo. Il legame con i Core Web Vitals è diretto. Una pagina lenta o instabile produce più "clic negativi", cioè visite in cui qualcuno clicca su un risultato, si spazientisce e torna subito ai risultati di ricerca. Sistemare i tuoi Core Web Vitals soddisfa un punteggio e, allo stesso tempo, elimina un motivo per cui i visitatori tornano su Google.
La cronologia più lunga
I Core Web Vitals non sono comparsi dal nulla nel 2020. Google ci lavora da oltre dieci anni:
| Anno | Cambiamento | Perché conta oggi |
|---|---|---|
| 2011 | L'aggiornamento Panda colpisce i contenuti di bassa qualità | Ha stabilito che la qualità percepita dall'utente influisce sul ranking oltre le parole chiave |
| 2014 | HTTPS diventa un fattore di ranking | Prima volta in cui un fattore tecnico, non legato ai contenuti, è stato confermato come segnale |
| 2018 | Aggiornamento Mobile Page Speed | La velocità delle pagine su mobile ottiene un proprio segnale esplicito |
| 2020 | Annuncio ufficiale dei Core Web Vitals (aggiornamento Page Experience) | Arrivano tre metriche misurabili: LCP, FID e CLS |
| 2024 | FID sostituito da INP (12 marzo) | La reattività viene misurata sull'intera visita invece che sul primo clic |
Controllare i Core Web Vitals in Google Search Console, passo per passo
Search Console resta il posto gratuito e autorevole in cui vedere come i dati sul campo di Google valutano le tue pagine. Ecco come aprirlo e leggerlo correttamente.
Aprire il report
- Accedi a Google Search Console e seleziona la tua proprietà.
- Nella barra laterale a sinistra, sotto Experience, clicca su Core Web Vitals.
- Vedrai due grafici riepilogativi, per Mobile e Desktop. Clicca su Open report sotto uno dei due.
- Ogni report mostra i gruppi di URL ordinati per stato: Poor, Need improvement e Good.
Leggere i gruppi di URL
Per impostazione predefinita, Search Console non riporta i singoli URL. Raggruppa le pagine simili, di solito per template, il che ha senso perché le pagine prodotto che condividono lo stesso layout avranno con ogni probabilità lo stesso problema di Core Web Vitals.
Entra in un gruppo "Poor" e vedrai quale metrica sta fallendo (LCP, INP o CLS), un campione di URL interessati e il numero di URL nel gruppo. Una pagina la cui valutazione dei core web vitals risulta "Failed" di solito si diagnostica qui, per template e non a tentativi su una sola pagina.
Dopo aver sistemato qualcosa
Una volta pubblicata una correzione, torna nel report e clicca su Validate fix sul gruppo di URL interessato. Google esegue una nuova scansione di un campione di quegli URL nei giorni successivi e aggiorna lo stato quando arrivano abbastanza dati di utenti reali. Possono servire da due a quattro settimane, perché i dati sul campo richiedono un campione reale di visite e una singola scansione non può fornirlo.
Le tre metriche e le loro soglie
| Metrica | Cosa misura | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo fino al rendering dell'elemento visibile più grande | 2,5 secondi o meno | 2,5–4 secondi | Oltre 4 secondi |
| INP (Interaction to Next Paint) | Ritardo tra un'azione dell'utente e la risposta visiva successiva | 200ms o meno | 200–500ms | Oltre 500ms |
| CLS (Cumulative Layout Shift) | Quanto il contenuto visibile si sposta in modo inatteso | 0,1 o meno | 0,1–0,25 | Oltre 0,25 |
Google valuta tutte e tre le metriche al 75° percentile dei caricamenti di pagina, secondo la documentazione sui Core Web Vitals di web.dev. Almeno tre visite reali su quattro devono rientrare in "Good" perché la pagina superi la valutazione.
Quando Google Search Console basta, e quando no
La maggior parte delle guide salta questo punto. Il report Core Web Vitals di Search Console è gratuito e usa dati di visitatori reali, e per molti siti è davvero sufficiente. Ha però dei limiti.
Dove Search Console fa il suo lavoro
- Gestisci un solo sito con pochi template, quindi la vista per gruppi di URL ti dice esattamente quale template è rotto.
- Stai controllando un calo isolato o ti servono solo dati sul campo. Se una singola pagina viene improvvisamente segnalata come "Poor" dopo un aggiornamento dei contenuti, i dati sul campo di Search Console insieme al Website Speed Test gratuito di solito individuano la causa. Search Console mostra cosa accade agli utenti reali ma non dice quale script o immagine l'abbia provocato.
Dove serve qualcosa in più di Search Console
- Una pagina ha troppo poco traffico per generare dati sul campo. Google richiede un volume minimo di visite reali prima di riportare un punteggio, quindi le pagine con poco traffico mostrano "no data" anche se sono davvero lente.
- Devi risalire alla causa effettiva. Search Console ti dà la metrica e il template. Per scoprire quale script di terze parti sta bloccando il main thread servono Chrome DevTools o uno strumento di laboratorio come Lighthouse.
- Il problema si ripresenta a ogni rilascio. Se ogni deploy reintroduce uno spostamento del layout, ti serve un monitoraggio nella tua pipeline di build invece di un controllo mensile del report.
- Usi una piattaforma con cause legate ai plugin. Su Shopify, un'app di terze parti è spesso la vera origine di un punteggio INP lento, e per risolverlo devi sapere quali app Shopify intervengono davvero sui Core Web Vitals così da non aggiungere altro peso di tracciamento.
Search Console ti dice che qualcosa non va e più o meno dove. Raramente ti dice con esattezza perché, fino al singolo script o foglio di stile.
Cause comuni e soluzioni per metrica
| Metrica | Causa tipica | Prima cosa da controllare | Chi di solito la risolve |
|---|---|---|---|
| LCP | L'immagine hero o il blocco di testo principale si carica in ritardo | L'elemento LCP è individuabile nell'HTML grezzo? | Sviluppatore frontend o provider di hosting |
| LCP | Risposta lenta del server (TTFB alto) | Tempo di risposta del server e caching | Team di hosting o backend |
| INP | Un task JavaScript lungo blocca il main thread | Quale azione dell'utente risulta in ritardo? | Sviluppatore frontend |
| INP | Script di terze parti pesanti (pubblicità, widget di chat, tracker) | Verifica quali script vengono eseguiti durante l'interazione | Marketing e sviluppo, insieme |
| CLS | Immagini o annunci senza dimensioni riservate | Il layout si sposta dopo il caricamento? | Sviluppatore frontend o team dei contenuti |
| CLS | Web font che causano il reflow del testo | Il font di riserva è impostato correttamente? | Sviluppatore frontend |
Errori comuni dei team con le novità sui Core Web Vitals
La maggior parte degli errori nasce dal trattare i Core Web Vitals come un unico punteggio da massimizzare, quando in realtà sono tre problemi distinti.
- Inseguire un 100 perfetto su PageSpeed Insights. A Google interessa solo che tu superi la soglia "Good", e oltre quella soglia stai spendendo budget per miglioramenti invisibili.
- Testare solo la homepage. La tua homepage può andare bene mentre tutte le pagine prodotto falliscono, quindi usa la vista per gruppi di URL invece di un singolo controllo a campione.
- Ignorare i dati mobile. I risultati su desktop di solito sono migliori di quelli su mobile, e il mobile è dove avvengono la maggior parte delle visite e degli abbandoni.
- Correggere tutti gli avvisi gialli in una volta. Dai priorità prima alle pagine legate a ricavi o lead. Un archivio del blog lento può aspettare.
- Saltare i test di interazione reale per INP. Una pagina può sembrare veloce al caricamento e fallire comunque INP nel momento in cui qualcuno tocca un menu a tendina o un filtro.
- Chiudere il ticket prima che i dati si allineino. I dati sul campo richiedono visite reali dopo la pubblicazione di una correzione, di solito qualche settimana, prima che lo stato si aggiorni.
I Core Web Vitals si affiancano anche a un altro segnale di qualità che Google promuove da anni, l'accessibilità. Una pagina con un contrasto cromatico scarso o senza testo alternativo spesso non rispetta gli stessi criteri stabiliti dalle Web Content Accessibility Guidelines (WCAG) del W3C, lo standard ufficiale alla base della maggior parte degli audit di accessibilità. Queste pagine spesso condividono le cause di fondo con quelle che hanno problemi di spostamento del layout, ed è uno dei motivi per cui risolvere i problemi di accessibilità tende a migliorare allo stesso tempo la SEO. Se non sei sicuro di dove si collochi la tua esposizione legale, consulta cosa richiede davvero la legge sull'accessibilità e cosa correggere per primo insieme alla pulizia dei tuoi Core Web Vitals.
Novità sui Core Web Vitals per editori e siti di news
Se il tuo sito funziona come editore di notizie, i problemi di velocità e stabilità si sommano ai problemi di indicizzazione. Un template lento rischia un punteggio CLS "Poor" e può anche rallentare la velocità con cui i nuovi articoli vengono scansionati.
Alcune correzioni correlate tendono ad andare insieme quando vuoi un'indicizzazione rapida e un punteggio pulito. Comincia ripulendo gli errori della sitemap di Google News così che i nuovi articoli compaiano in fretta. Su WordPress, verifica che la tua configurazione di Yoast News SEO non aggiunga script che bloccano il rendering ai template degli articoli. Poi rivedi la guida più ampia per far indicizzare e posizionare rapidamente gli articoli di news, perché un template di articolo pesante spesso fallisce contemporaneamente i controlli di INP e di velocità di scansione.
Se la tua attività compare anche nella ricerca locale, tieni d'occhio le recenti modifiche a Google Business Profile insieme al lavoro sui Core Web Vitals. Entrambi alimentano la stessa immagine di esperienza della pagina che Google costruisce del tuo brand.
Perché è legato al comportamento di clic
Ricorda il meccanismo NavBoost visto prima: Google considera un segnale negativo i clic che tornano subito alla pagina dei risultati, e una pagina lenta o instabile ne produce di più. Migliorare i tuoi Core Web Vitals protegge le prestazioni del tuo click-through. Per la matematica di fondo su cosa rende forte un risultato, vale la pena dare una rapida occhiata alla formula del click-through rate e ai benchmark, e una pagina veloce e stabile è uno dei modi più economici per proteggere quel valore.
Dare priorità alle correzioni: un metodo semplice
Invece di sistemare ogni URL segnalato nell'ordine in cui Search Console li elenca, segui questa sequenza:
- Scegli prima i template legati a ricavi o lead, come pagine prodotto, pagine di servizio e landing page.
- Controlla i dati sul campo prima di quelli di laboratorio. Il report di Search Console e i dati sul campo di CrUX riflettono visite reali, mentre strumenti di laboratorio come Lighthouse simulano una singola esecuzione.
- Individua la metrica specifica che fallisce. LCP, INP e CLS richiedono ciascuno una correzione diversa, e un generico ticket "rendilo più veloce" fa sprecare tempo agli sviluppatori.
- Prova un URL rappresentativo del gruppo prima di modificare l'intero template.
- Valida con uno strumento di laboratorio prima di pubblicare, poi convalida la correzione in Search Console.
- Monitora per qualche settimana, perché i dati sul campo impiegano tempo ad allinearsi a una correzione pubblicata.
Domande frequenti
Quali sono le ultime novità sui Core Web Vitals nel 2026?
Il cambiamento recente più importante resta la sostituzione, il 12 marzo 2024, di First Input Delay con Interaction to Next Paint. Da allora, la maggior parte delle "novità" è stata l'analisi della documentazione trapelata di Google, che conferma come interagiscono il comportamento di clic e i Core Web Vitals, e non è arrivata nessuna nuova metrica ufficiale.
Google ha tolto i Core Web Vitals dal ranking?
No. Google ha ripetuto più volte che i Core Web Vitals sono uno dei tanti segnali e che la pertinenza e la qualità dei contenuti hanno ancora più peso. Punteggi scarsi non impediranno a una pagina di posizionarsi del tutto, ma possono far perdere a una pagina altrimenti alla pari il confronto con un concorrente più veloce.
Quanto tempo ci vuole perché una correzione compaia in Search Console?
I dati sul campo richiedono un nuovo campione di visite reali dopo la pubblicazione di una correzione, e di solito servono da un paio di settimane a un mese prima che lo stato si aggiorni nel report Core Web Vitals.
PageSpeed Insights è lo stesso del report Core Web Vitals di Search Console?
No. PageSpeed Insights testa un URL alla volta e unisce dati di laboratorio e dati sul campo. Il report di Search Console raggruppa molti URL per template usando solo dati sul campo di visite reali, il che lo rende più adatto a dare priorità alle correzioni su un intero sito.
INP sostituisce del tutto i Core Web Vitals, o solo una metrica?
INP ha sostituito solo FID, quindi LCP e CLS restano invariati al suo fianco.
Cosa fare subito
Apri oggi il report Core Web Vitals in Search Console, ordina per stato e scegli il gruppo di URL "Poor" legato al template con più traffico. Passa una pagina di quel gruppo nel Website Speed Test gratuito per confermare quale metrica (LCP, INP o CLS) sta fallendo prima di dare indicazioni a uno sviluppatore. Se vuoi vedere cosa farebbe emergere una revisione tecnica completa del tuo sito, con i Core Web Vitals inclusi, parla con il team e chiedi un report di esempio costruito sui tuoi URL.
Risorse / Riferimenti
Letture correlate: Core Web Vitals Monitoring: The Free Search Console Fix.
Fonti
Sull'autore
SearchBlueprint ha ricercato, scritto e valutato questo articolo con la stessa pipeline di contenuti che i nostri clienti usano sui loro siti. Il punteggio indicato nella firma è quello che il nostro motore di contenuti ha assegnato a questa pagina prima della pubblicazione. Nulla qui è rivisto a mano, ed è proprio questo il punto: è il risultato del prodotto, pubblicato dove chiunque può verificarlo.