Core Web Vitals: cosa misurano e come migliorarli

I Core Web Vitals (in italiano Segnali web essenziali) sono tre metriche con cui Google misura l'esperienza reale di chi apre una pagina: quanto in fretta compare il contenuto principale (LCP), quanto risponde ai clic e ai tocchi (INP) e quanto resta ferma la pagina mentre si carica (CLS). Per Google una pagina è buona quando rispetta le soglie di tutte e tre nel 75% delle visite.

Questa guida ti dice cosa misura ciascuna metrica, dove leggere i dati veri e quali interventi spostano davvero i numeri. Poi ti mostro le scelte di velocità che si leggono nel codice di seo.srl, come esempio di un sito costruito per non dover rincorrere i problemi dopo.

Le tre metriche e le soglie#

La pagina Core Web Vitals su web.dev (ultimo aggiornamento: 31 ottobre 2024) elenca le tre metriche e il criterio per superarle. Le soglie sono le stesse nelle pagine dedicate a LCP, INP e CLS.

LCP: quando compare il contenuto principale#

L'LCP è il momento in cui finisce di essere disegnato il contenuto più grande visibile nella schermata, contato dall'inizio della navigazione. Secondo web.dev può essere un'immagine, un video (conta il poster o il primo fotogramma), un elemento con immagine di sfondo da CSS o un blocco di testo.

INP: quanto risponde la pagina#

L'INP osserva la latenza di clic con il mouse, tocchi sullo schermo e pressioni di tasti per tutta la visita e riporta, tolti i casi anomali, l'interazione più lenta. Passare il mouse, scorrere e fare zoom non contano. È il motivo per cui un sito lento a rispondere dopo il caricamento (un menu che si apre in ritardo, un filtro che si blocca) può avere un LCP ottimo e un INP scarso.

L'INP ha sostituito il First Input Delay (FID) il 12 marzo 2024, come annunciato dal blog di web.dev. Se trovi ancora il FID in un vecchio report o in una guida, il dato non è più quello che Google usa.

CLS: quanto si sposta la pagina#

Il CLS somma gli spostamenti inattesi di layout e riporta la sequenza più grave: una serie di spostamenti a meno di un secondo l'uno dall'altro, per un massimo di cinque secondi. Gli spostamenti entro 500 ms da un input dell'utente (un clic, un tocco, un tasto) non si contano, perché sono attesi. È il fastidio di chi sta per toccare un pulsante e lo vede scendere perché è arrivato un banner.

Cosa significa il 75° percentile#

Le soglie non si applicano alla tua visita di prova. Web.dev chiede di misurare il 75° percentile dei caricamenti di pagina, separando mobile e desktop: una pagina supera la valutazione se a quel livello rispetta le soglie di tutte e tre le metriche.

In pratica significa che tre visite su quattro devono stare dentro la soglia. Il quarto più lento degli utenti, quelli con il telefono più vecchio o la rete peggiore, non entra nel calcolo. Per questo un sito che "sul mio computer va benissimo" può risultare lento nei dati reali: il percentile si calcola su chi visita davvero, non su chi lo sviluppa.

Dati di campo e dati di laboratorio#

La documentazione di PageSpeed Insights (aggiornata il 21 ottobre 2024) distingue due tipi di dati che spesso danno risultati diversi.

• Dati di campo. Vengono dal Chrome User Experience Report (CrUX), che raccoglie le misure di utenti reali di Chrome. Riguardano un periodo di 28 giorni e sono riportati al 75° percentile.
• Dati di laboratorio. Vengono da Lighthouse, che simula un caricamento in condizioni fisse: per il mobile un telefono di fascia media su rete mobile, per il desktop un dispositivo emulato su rete cablata. Servono per capire cosa correggere e per provare una modifica prima di pubblicarla.

I due numeri possono non coincidere: i dati di campo sono lo storico di molti dispositivi e reti, il laboratorio è una sola prova. C'è anche una differenza sull'INP. Secondo web.dev alcuni strumenti di laboratorio non lo riportano, perché osservano solo il caricamento della pagina senza interazioni; in quei casi il Total Blocking Time può servire come indicatore approssimativo, ma non sostituisce l'INP.

La regola di lavoro che ne ricavo: il dato di campo dice se hai un problema, il laboratorio dice dove cercarlo e se la correzione funziona. Una correzione non si valuta sul punteggio di Lighthouse, ma sui dati di campo delle settimane dopo.

Dove leggere i Core Web Vitals del tuo sito#

Report Core Web Vitals di Search Console#

Il report Core Web Vitals di Search Console usa i dati di campo di CrUX per LCP, INP e CLS, con mobile e desktop separati. Raggruppa le pagine simili e assegna a ogni gruppo uno stato (buono, da migliorare, scarso) che coincide con quello della metrica peggiore. Le pagine con pochi dati restano fuori e il report mostra solo URL indicizzati.

Vai da qui quando devi capire quanti gruppi di pagine hanno un problema. Dopo una correzione, il pulsante di verifica monitora i dati per 28 giorni. Se non hai ancora Search Console configurato, trovi come si usa nella guida a Google Search Console.

PageSpeed Insights#

PageSpeed Insights analizza un singolo indirizzo e mostra in alto i dati di campo (se esistono) e sotto il rapporto di Lighthouse. Quando la pagina non ha abbastanza dati reali, ricade sui dati dell'intero sito; se mancano anche quelli, mostra solo il laboratorio. Può succedere alle pagine nuove o poco visitate, perché servono abbastanza campioni di utenti.

Altri strumenti#

Gli strumenti per sviluppatori di Chrome permettono di registrare una sessione e di vedere quale interazione ha pesato sull'INP. Servono quando il dato di campo è scarso e devi trovare quale script o quale evento lo causa.

Quanto contano per il posizionamento#

La risposta di Google è più prudente di molti titoli che si leggono in giro. Nella pagina sulla page experience (aggiornata il 22 settembre 2026) scrive che i suoi sistemi di ranking cercano di premiare i contenuti con una buona esperienza di pagina e che non esiste un segnale unico. I Core Web Vitals sono l'aspetto che i sistemi usano, e Google consiglia di ottenere buoni risultati, avvertendo però che buoni risultati nel report non garantiscono le prime posizioni, perché una buona esperienza di pagina comprende più aspetti dei soli punteggi dei Core Web Vitals.

La pagina dedicata ai Core Web Vitals in Search Central (aggiornata il 10 dicembre 2025) dice di raccomandare con decisione ai proprietari dei siti di ottenere buoni Core Web Vitals per avere successo nella Ricerca, e li colloca, insieme agli altri aspetti dell'esperienza di pagina, tra le cose che i sistemi di ranking di base cercano di premiare.

Come la leggo io: Google li raccomanda ma non promette posizioni. Misurano inoltre cose che chi usa il sito percepisce: l'attesa, la pagina che salta, il pulsante che non risponde. Per un manager questo basta a metterli in agenda, senza bisogno di promettere posizioni.

Come migliorare l'LCP#

Web.dev, nella guida per ottimizzare l'LCP (aggiornata il 31 marzo 2025), divide il tempo in quattro parti, con una proporzione indicativa: il tempo fino al primo byte (circa 40%), il ritardo prima che il browser inizi a scaricare la risorsa (meno del 10%), il tempo di download della risorsa (circa 40%) e il ritardo prima che l'elemento venga disegnato (meno del 10%). Guardare in quale parte stai perdendo tempo evita di ottimizzare a caso.

• Metti fetchpriority="high" sull'immagine che sarà l'LCP. La guida avverte che usarlo su più di una o due immagini lo rende inutile.
• Non caricare in lazy l'immagine dell'LCP. La guida lo indica come un effetto negativo diretto sull'LCP. Il lazy loading va solo sulle immagini fuori dalla prima schermata.
• Anticipa le risorse che il browser scopre tardi. Se l'immagine compare solo nel CSS o viene inserita da JavaScript, il browser la trova dopo: serve un <link rel="preload"> con priorità alta.
• Riduci il peso e avvicina la risorsa. Immagini in formato leggero e della dimensione giusta, servite da una CDN o dalla stessa origine dell'HTML quando possibile.

<img src="copertina.webp" alt="Descrizione dell'immagine"
     width="1200" height="675"
     fetchpriority="high">

Come migliorare l'INP#

La guida a ottimizzare l'INP (aggiornata il 2 settembre 2025) scompone ogni interazione in tre fasi: il ritardo di ingresso (dal gesto all'avvio dei gestori dell'evento), il tempo di esecuzione dei gestori e il ritardo di presentazione (fino al disegno del fotogramma successivo). Per trovare il problema devi sapere in quale fase si perde il tempo.

• Riduci il JavaScript. Secondo la guida ai task lunghi, un task che dura più di 50 millisecondi è un "task lungo": mentre gira, il browser non può gestire le interazioni. Dopo che uno script è stato scaricato, il browser deve analizzarlo, compilarlo ed eseguirlo, e questo, scrive web.dev, può produrre task lunghi sul thread principale.
• Spezza il lavoro lungo. Con setTimeout o con scheduler.yield() lasci al browser la possibilità di gestire un tocco tra un pezzo e l'altro. Secondo la guida ai task lunghi (aggiornata il 19 dicembre 2024) scheduler.yield() non è supportato da Safari, quindi serve un'alternativa. Fai prima l'aggiornamento visibile all'utente e rimanda ciò che può aspettare.
• Tieni piccola la struttura della pagina. Un DOM molto grande rallenta il rendering, sia al caricamento sia dopo ogni interazione. Web.dev indica per i blocchi fuori schermo la proprietà CSS content-visibility, che di fatto rimanda il rendering degli elementi finché non si avvicinano alla schermata.
• Evita di leggere e scrivere lo stile nello stesso task. Modificare uno stile da JavaScript e leggerlo subito dopo costringe il browser a ricalcolare il layout in quel momento (layout thrashing).

Gli script di terze parti (chat, tag di tracciamento, widget) vanno valutati con la stessa regola: ognuno aggiunge JavaScript da eseguire sul thread principale. La domanda da farsi per ciascuno è se serve a tutti i visitatori o solo a chi ha dato un consenso.

Come migliorare il CLS#

La guida a ottimizzare il CLS (aggiornata il 7 febbraio 2025) tratta sei aree, con la correzione di ciascuna: le quattro cause più comuni, più le animazioni e la back/forward cache.

La prima riga è la correzione più economica: dichiarare le dimensioni di un'immagine richiede due attributi nel codice.

TTFB e server: la base di tutto il resto#

Il TTFB (Time To First Byte) misura il tempo dall'inizio della navigazione al primo byte della risposta. Secondo web.dev (aggiornata a novembre 2025) è la somma di reindirizzamenti, ricerca DNS, connessione e negoziazione TLS e tempo di risposta del server fino al primo byte. Non è un Core Web Vital, ma pesa sull'LCP: è la prima delle quattro parti viste sopra, e arriva prima di tutto il resto. La stessa pagina indica come riferimento di massima 0,8 secondi o meno per un buon valore e oltre 1,8 secondi per uno scarso.

La guida a ottimizzare il TTFB (aggiornata il 28 novembre 2025) indica quattro leve.

• Hosting. È la prima cosa da considerare. Se il TTFB resta alto anche su un hosting dedicato, web.dev suggerisce di rivalutare il fornitore.
• CDN. I server vicini all'utente riducono la latenza. La guida la indica come priorità alta per chi non ne usa una.
• Cache. Con le intestazioni Cache-Control corrette la CDN serve il contenuto senza interrogare ogni volta il server. Anche un tempo di cache breve, scrive web.dev, può dare vantaggi misurabili ai siti molto frequentati e aggiornati spesso.
• Reindirizzamenti. Ogni redirect sotto il tuo controllo, per esempio da http a https o da una versione dell'indirizzo a un'altra, aggiunge tempo prima del primo byte. Se dopo una migrazione hai catene di redirect, conviene accorciarle; sul tema c'è la pagina sulla migrazione di un sito.

Per l'altra componente, la ricerca DNS, trovi come funziona nella pagina sui server DNS. Se il sito è su WordPress, hosting, versione del software e plugin sono i punti da controllare per primi, e la manutenzione dei siti WordPress ha una pagina dedicata.

Le scelte di velocità di seo.srl, lette nel codice#

Qui non trovi punteggi di seo.srl, ma le scelte scritte nel codice del sito: ognuna corrisponde a una raccomandazione vista sopra.

Font: un dominio in meno e nessun salto del testo#

Il sito non chiede i font a un server esterno: i file stanno nei pacchetti @fontsource-variable e li importa il foglio di stile. Questo toglie la connessione a un dominio terzo prima di poter disegnare il testo. Nella testata della pagina due file, il sottoinsieme latino dei due font, sono precaricati con rel="preload", e il commento nel codice spiega che sono gli stessi file che il CSS richiama, quindi non si scaricano due volte.

Il secondo intervento riguarda il CLS. Nel CSS i due font hanno un ripiego con metriche allineate (size-adjust e le tre sovrascritture di ascent, descent e line-gap), come quello che web.dev consiglia per ridurre le differenze tra ripiego e font vero. Se il font arriva dopo il primo disegno, il testo cambia faccia ma occupa quasi lo stesso spazio.

Immagini: dimensioni dichiarate, priorità alta solo dove serve#

La regola sta nella funzione che prepara il corpo degli articoli. Per ogni <img> nel corpo, se manca, aggiunge loading="lazy" e decoding="async". Se la pagina non ha copertina, la prima immagine del corpo è considerata quella dell'LCP: prende loading="eager" e fetchpriority="high", anche se nel JSON era scritto lazy. Se la pagina ha una copertina, quel ruolo ce l'ha la copertina, che nel template è già eager, ad alta priorità e con 1200 per 675 dichiarati. È l'applicazione quasi letterale di quanto dice web.dev: priorità alta su una sola immagine e mai lazy sull'immagine principale.

Le dimensioni dichiarate sono il rimedio per il CLS delle immagini. Per le immagini dell'archivio ogni <img> le ha, con le proporzioni del file, e un test automatico blocca la pubblicazione se mancano. Le copertine sono JPG di 1200 per 675 pixel.

Animazioni e tracciamento#

Le regole di design del sito vietano le animazioni di ingresso. Gli elementi non compaiono in dissolvenza o scorrendo: il contenuto è subito al suo posto. L'unica animazione è il report di esempio in home, e rispetta prefers-reduced-motion.

Per il tracciamento il sito usa Google Analytics 4 con gtag.js diretto, senza Google Tag Manager, caricato solo dopo il clic su "Accetta". Senza consenso non parte nessuno script verso googletagmanager.com o google-analytics.com. Per le metriche significa che chi non accetta non scarica né esegue quel JavaScript sul thread principale; chi accetta lo scarica in modo asincrono. È una scelta di privacy prima che di velocità, con un effetto sul JavaScript che la pagina esegue.

Il codice non dice quali numeri escono dai dati di campo: per quello bisogna aprire Search Console. Dice che le scelte sono coerenti con le indicazioni di web.dev, che è il punto di partenza giusto per non dover correggere dopo.

Da dove cominciare su un sito esistente#

1. Apri il report Core Web Vitals di Search Console e guarda quale metrica e quale gruppo di pagine sono scarsi, per mobile e desktop.
2. Prendi un indirizzo rappresentativo del gruppo e analizzalo con PageSpeed Insights: confronta i dati di campo con quelli di laboratorio.
3. Se l'LCP è il problema, trova l'elemento e la parte (TTFB, ritardo, download, disegno) in cui si perde tempo. Se è l'INP, registra l'interazione lenta con gli strumenti di Chrome. Se è il CLS, cerca immagini senza dimensioni, font e contenuti inseriti in ritardo.
4. Correggi una causa alla volta e misura di nuovo in laboratorio.
5. Avvia la verifica in Search Console e aspetta i 28 giorni di dati di campo prima di dire che il problema è risolto.

Se la velocità fa parte di un controllo più ampio del sito, si inserisce nell'audit SEO. Se invece il sito va rifatto dalle fondamenta, la pagina sulla realizzazione di siti web descrive come lavoriamo. L'insieme delle verifiche tecniche è nella guida alla SEO tecnica.