Core Web Vitals: LCP, INP e CLS spiegati (2026)

Controllo rapido: quando i valori sono buoni

LCP fino a 2,5 secondi, INP fino a 200 millisecondi, CLS fino a 0,1, misurati al 75° percentile delle visite reali (web.dev). Mobile e desktop si valutano separatamente. Un buon punteggio Lighthouse aiuta a trovare i problemi, ma non equivale ad avere superato i Core Web Vitals con gli utenti veri.

Le tre metriche e le loro soglie

Ogni metrica ha un limite per il valore buono e uno per il valore scadente. Una pagina supera la valutazione quando il 75° percentile delle visite reali è nella fascia buona.

Largest Contentful Paint (LCP): buono fino a 2,5 s, scadente oltre 4 s. Indica quando l'immagine o il blocco di testo più grande nell'area visibile è stato disegnato.
Interaction to Next Paint (INP): buono fino a 200 ms, scadente oltre 500 ms. Misura l'attesa tra un tocco, un clic o un tasto premuto e l'aggiornamento successivo dello schermo, lungo tutta la visita.
Cumulative Layout Shift (CLS): buono fino a 0,1, scadente oltre 0,25. Somma gli spostamenti imprevisti del layout, come il testo che scivola in basso quando un'immagine o un banner arriva in ritardo.

INP ha preso il posto di First Input Delay (FID) tra i Core Web Vitals nel marzo 2024. Uno strumento o un report che ti valuta ancora sul FID è rimasto indietro.

Dati reali e dati di laboratorio

I dati reali arrivano dagli utenti di Chrome tramite il Chrome UX Report (CrUX) e coprono gli ultimi 28 giorni (PageSpeed Insights). Sono quelli che usa Google. Se una pagina ha poche visite, PageSpeed mostra i dati dell'intero sito; se non bastano nemmeno quelli, i dati reali mancano, cosa frequente per siti piccoli e attività locali.

I dati di laboratorio vengono da un solo caricamento simulato con Lighthouse, di solito su un telefono di fascia media con connessione rallentata. Sono ripetibili e perfetti per trovare le cause, ma non possono misurare INP, perché nessuno tocca la pagina. Al suo posto Lighthouse riporta il Total Blocking Time (TBT), che segnala gli stessi problemi di JavaScript.

Usa il laboratorio per capire cosa non va e i dati reali per confermare che la correzione ha funzionato. I dati reali cambiano lentamente: la finestra di 28 giorni deve prima scorrere.

Diagnosi di una pagina lenta in cinque minuti

Testa l'URL esatto da mobile e annota l'elemento LCP, le richieste che bloccano il rendering e le immagini pesanti.
Guarda i dati reali a parte. Se CrUX non ha dati, registralo come traffico insufficiente, non come promosso o bocciato.
Trova il ritardo principale. Un'immagine di copertina enorme si corregge in modo diverso da un server lento o da script che bloccano l'interazione.
Correggi una causa alla volta e ripeti il test sullo stesso URL, annotando cosa hai cambiato.
Segui l'andamento. Il laboratorio cambia subito, i dati reali si aggiornano gradualmente.

Controlla gratis la velocità del tuo sito: l'analisi esegue Google PageSpeed su mobile e desktop per un URL. La pagina test velocità sito web spiega come i due risultati diventano un unico punteggio.

Come migliorare LCP

Un LCP lento ha quasi sempre una di quattro origini: il server risponde tardi, un foglio di stile o uno script blocca il rendering, l'immagine principale viene scoperta tardi, oppure è semplicemente troppo pesante.

Tieni basso il tempo di risposta del server (TTFB) con la cache di pagina e, se il pubblico è lontano dal server, una CDN.
Non caricare in lazy loading l'immagine principale. Assegnale fetchpriority="high" e, se è impostata via CSS, precaricala.
Servi l'immagine principale in AVIF o WebP, alle dimensioni in cui viene mostrata, con srcset per i diversi schermi.
Metti inline il CSS critico o tieni piccolo il foglio di stile principale, e rimanda gli script che non servono alla prima schermata.
Dove possibile sostituisci slider e video in autoplay in apertura con una sola immagine statica.

Come migliorare INP

Un INP scadente vuol dire quasi sempre che il thread principale è occupato proprio quando l'utente interagisce. La causa abituale è il JavaScript, e gli script di terze parti ne sono spesso la parte più grande.

Togli gli script che non usi più, soprattutto i residui di vecchi plugin, app e prove fatte nel tag manager.
Carica chat, mappe di calore e widget delle recensioni dopo che la pagina è interattiva, oppure solo quando l'utente li apre.
Spezza i task lunghi in parti più piccole e tieni leggeri i gestori dei clic, così il browser può aggiornare lo schermo subito dopo ogni interazione.
Evita DOM enormi: menu molto estesi e griglie di prodotti lunghissime rallentano ogni aggiornamento.

Come migliorare CLS

Il layout si sposta quando il browser non sa quanto spazio occuperà un elemento finché non è caricato.

Indica width e height (oppure aspect-ratio) su ogni immagine, video e iframe.
Riserva lo spazio per banner, spazi pubblicitari e contenuti incorporati. Il banner dei cookie dovrebbe sovrapporsi alla pagina invece di spingere giù il contenuto.
Usa font-display: swap con un font di riserva di dimensioni simili, oppure precarica il font principale, per ridurre il riassestamento del testo.
Non inserire contenuti sopra quelli esistenti, a meno che non sia l'utente a chiederlo.

Cosa mostra il report di Sitequiry

Sitequiry esegue Google PageSpeed Insights su mobile e desktop e mostra LCP, FCP, TBT e CLS su fasce che usano le soglie qui sopra, insieme ai fotogrammi del caricamento e al peso della pagina per tipo di risorsa. Quando Google ha dati CrUX per l'URL o per l'origine, il report li usa. Quando PageSpeed non risponde, il report lo dice e indica il punteggio velocità come stima, senza inventare numeri.

Domande frequenti

I Core Web Vitals sono un fattore di ranking?

Google scrive che vengono usati dai suoi sistemi di ranking, ma che la Ricerca cerca sempre di mostrare i contenuti più pertinenti anche quando l'esperienza sulla pagina è meno buona (Google Search Central). Contano di più quando più risultati si equivalgono, e influiscono comunque su come i visitatori vivono ogni pagina.

Perché il punteggio di PageSpeed cambia a ogni test?

I test di laboratorio dipendono dalla rete, dal carico del server e dagli script di terze parti in quel momento. Qualche punto di differenza è normale: guarda l'andamento e le singole metriche, non un solo numero.

Il mio sito non ha dati reali. È un problema?

No. Significa solo che il traffico da Chrome non basta perché CrUX pubblichi i numeri. Usa le metriche di laboratorio per trovare e correggere i problemi; i dati reali compariranno da soli quando il traffico crescerà.

Meglio ottimizzare prima per mobile o per desktop?

Di solito mobile. Google usa la versione mobile dei contenuti per l'indicizzazione e il ranking (Google Search Central) e i telefoni sono più lenti dei computer. Controlla però la ripartizione nei tuoi dati di analytics: se la maggior parte dei visitatori usa il desktop, i suoi dati reali meritano la stessa attenzione.

Perché Lighthouse è buono ma CrUX non passa?

Lighthouse simula un caricamento su un solo dispositivo, CrUX riflette 28 giorni di visite reali su tanti dispositivi e reti. Telefoni più lenti, script di terze parti che si caricano dopo e interazioni su pagine affollate emergono solo nei dati reali.

Perché INP manca nel test di laboratorio?

INP ha bisogno di interazioni vere, e un test di laboratorio non tocca né scrive. Lighthouse riporta il Total Blocking Time, che indica gli stessi problemi del thread principale.

Quale metrica conviene correggere per prima?

Quella che non passa nei dati reali, partendo da mobile. Senza dati reali comincia da LCP: è il problema più comune e di solito ha una causa chiara, come un'immagine di copertina pesante o un server lento.

Core Web Vitals: cosa sono LCP, INP e CLS e come migliorarli