Core Web Vitals non superati? Come migliorare LCP, INP e CLS

Di SEOgrinder · Pubblicato il 4 novembre 2026 · 10 min di lettura

Risposta breve: una valutazione dei Core Web Vitals non superata significa che almeno una di tre metriche non rispetta la soglia per i visitatori reali: l’LCP (caricamento) deve essere di 2,5 secondi o meno, l’INP (reattività) di 200 millisecondi o meno e il CLS (stabilità visiva) di 0,1 o meno, ciascuno misurato al 75° percentile. Trova la metrica che fallisce nei dati dei visitatori reali, non nel punteggio di laboratorio, e correggi prima quella. Google dice che i suoi sistemi di ranking usano i Core Web Vitals, ma valori buoni non garantiscono una posizione in cima.

Che cosa significa «Core Web Vitals non superati»?

I Core Web Vitals sono la parte dell’iniziativa Web Vitals di Google che vale per ogni pagina web. web.dev indica tre metriche, una per ciascun aspetto dell’esperienza:

Metrica	Che cosa misura	Valore buono
LCP, Largest Contentful Paint	Caricamento: quando compare l’immagine, il blocco di testo o il video più grande nell’area visibile	2,5 secondi o meno
INP, Interaction to Next Paint	Reattività: quanto in fretta la pagina reagisce in modo visibile a un clic, un tocco o la pressione di un tasto	200 millisecondi o meno
CLS, Cumulative Layout Shift	Stabilità visiva: quanto il contenuto visibile si sposta mentre usi la pagina	0,1 o meno

I valori vengono giudicati al 75° percentile dei caricamenti di pagina, separatamente per mobile e desktop. In parole semplici: su tre visite su quattro il valore deve essere buono, e telefono e desktop ricevono ciascuno un proprio verdetto. web.dev dice agli strumenti di considerare superata una pagina se raggiunge gli obiettivi al 75° percentile per tutte e tre le metriche. Basta quindi una sola metrica rossa per non superare la valutazione.

Un dettaglio al limite: web.dev scrive per INP e CLS «or less», cioè «o meno», mentre la documentazione di Google per la Ricerca scrive «less than 200 milliseconds» e «less than 0.1», cioè «meno di». Punta nettamente sotto la soglia e la differenza non conta.

Un cambiamento da conoscere: a marzo 2024 l’INP ha sostituito il First Input Delay (FID) come Core Web Vital, come dice l’annuncio su web.dev. Una guida che elenca ancora il FID è superata. Abbiamo letto tutte le pagine citate in questo articolo il 4 novembre 2026; la panoramica di web.dev è stata aggiornata l’ultima volta il 31 ottobre 2024.

I Core Web Vitals influenzano il posizionamento su Google?

Sì, secondo Google, ma senza indicare un peso. La pagina di Google sull’esperienza di pagina dice: «Core Web Vitals are used by our ranking systems.» Raccomanda valori buoni per avere successo nella Ricerca e aggiunge che non esiste un unico segnale di esperienza di pagina.

La stessa pagina è altrettanto chiara sui limiti. Buoni risultati nel report Core Web Vitals di Search Console o in strumenti di terzi «doesn’t guarantee that your pages will rank at the top of Google Search results», cioè non garantiscono che le tue pagine si posizionino in cima ai risultati. Dice anche che inseguire un punteggio perfetto solo per la SEO potrebbe non essere il modo migliore di usare il tuo tempo. Google cerca sempre di mostrare il contenuto più pertinente, anche quando l’esperienza di pagina è scarsa.

Quanto pesino le metriche, Google non lo pubblica, quindi non indichiamo nemmeno noi nessun numero. La nostra lettura, non un’affermazione di Google: considera le soglie un livello di qualità per i tuoi visitatori, porta tutte e tre i valori su «buono» e poi rimetti il tuo tempo nei contenuti. I sistemi di ranking principali di Google in genere valutano i contenuti pagina per pagina, quindi controlla ogni tipo di pagina che conta.

Dati di laboratorio o dati sul campo: quali contano per i Core Web Vitals?

La valutazione si basa sui dati sul campo: misure di visite reali. Il Chrome User Experience Report (CrUX) di Google li raccoglie da utenti reali di Chrome; li mostrano PageSpeed Insights e il report Core Web Vitals di Search Console. Secondo web.dev, un report CrUX copre un periodo di 28 giorni.

I dati di laboratorio nascono caricando la pagina una volta in una configurazione controllata: un dispositivo, una rete, un luogo. È ideale per trovare le cause e per provare una correzione prima della pubblicazione, ma la guida all’LCP avverte che «lab tests alone may not be entirely representative», cioè i soli test di laboratorio potrebbero non essere del tutto rappresentativi. Quando i due non concordano, la guida all’LCP dice di concentrarsi prima sui dati degli utenti reali. Le differenze hanno buone ragioni:

L’elemento LCP può cambiare. Un’esecuzione di laboratorio trova sempre lo stesso elemento. Le visite reali hanno altre dimensioni dello schermo, contenuti per utenti connessi o test A/B.
L’INP richiede persone vere. Lighthouse e altri strumenti di laboratorio caricano una pagina senza che nessuno clicchi, quindi non possono misurare l’INP. Il Total Blocking Time (TBT) è il sostituto in laboratorio; i miglioramenti del TBT possono migliorare l’INP.
Il CLS continua a contare dopo il caricamento. Le esecuzioni di laboratorio vedono per lo più il caricamento stesso. Sul campo, anche il contenuto che compare mentre i visitatori scorrono può spostare il layout.
Le cache aiutano i visitatori reali. I test di laboratorio di solito partono con la cache vuota, mentre chi torna sul sito e la back/forward cache caricano le pagine più in fretta.

Come leggere i tuoi numeri in quattro passaggi:

Inserisci il tuo indirizzo in PageSpeed Insights. La sezione «Discover what your real users are experiencing» (nome inglese dell’interfaccia) contiene i dati sul campo; «Diagnose performance issues» contiene l’esecuzione di laboratorio.
Controlla che cosa stai guardando. Passa da mobile a desktop e dal singolo URL all’intera origine (origin). Se un URL ha troppo pochi dati, PageSpeed Insights mostra al suo posto i dati dell’origine.
Trova la metrica oltre la soglia al 75° percentile. È la tua metrica debole. Con poco traffico non ci sono dati sul campo; usa i valori di laboratorio e misura tu stesso i tuoi visitatori con la piccola libreria web-vitals di web.dev.
Apri la diagnostica di laboratorio per quella metrica per vedere la causa e correggi prima quell’unica cosa.

Come migliorare l’LCP: l’elemento più grande compare troppo tardi

L’LCP indica quando vengono mostrati l’immagine, il blocco di testo o il video più grande nell’area visibile. La guida all’LCP di web.dev divide il tempo in quattro parti che sommate danno l’LCP: la risposta del server (TTFB), il ritardo prima che il browser inizi a caricare la risorsa LCP, il tempo che quella risorsa impiega a caricarsi e il ritardo fino alla visualizzazione dell’elemento. Trova la parte più grande prima di cambiare qualcosa: accorciarne una può soltanto spostare tempo in un’altra. Un’immagine compressa non aiuta se l’elemento resta nascosto finché non si carica uno script.

L’elenco delle correzioni più efficaci del team di Chrome comprende queste:

Rendi l’immagine LCP facile da trovare e dalle la priorità. Usa un normale <img> con src o srcset, non un data-src che richiede JavaScript. Preferisci il rendering lato server alla costruzione della pagina solo nel browser. Aggiungi fetchpriority="high" e togli loading="lazy" da questa sola immagine.
Accorcia la risposta del server. Servi e metti in cache i contenuti vicino ai visitatori, di solito con una CDN.

Lo stesso tag gestisce l’LCP e, tramite le dimensioni, il CLS:

<!-- Immagine principale: nell'HTML, alta priorità, non lazy, con dimensioni -->
<img src="/img/hero.webp" width="1200" height="630" alt="Breve descrizione" fetchpriority="high">

<!-- Immagini più in basso nella pagina: qui il lazy loading va bene -->
<img src="/img/team.webp" width="600" height="400" alt="Breve descrizione" loading="lazy">

Come migliorare l’INP: la pagina reagisce troppo lentamente

L’INP osserva ogni clic, tocco e pressione di tasto durante una visita e riporta più o meno il più lento (per le pagine con moltissime interazioni, i casi anomali vengono ignorati). Passare il mouse e scorrere non contano. Secondo la guida all’INP, ogni interazione ha tre parti: il ritardo dell’input, il tempo in cui girano i gestori di eventi e il ritardo fino alla visualizzazione del frame successivo. Il colpevole abituale è JavaScript che tiene occupato il thread principale. Le correzioni principali del team di Chrome:

Spezza le attività lunghe. Un’attività oltre i 50 millisecondi blocca il thread principale. Restituisci spesso il controllo: scheduler.yield() dove il browser lo supporta, setTimeout come metodo più vecchio.
Invia meno JavaScript. Trova il codice inutilizzato con lo strumento di copertura (coverage) di Chrome DevTools, dividi il codice che all’inizio non serve e ripulisci i vecchi tag nel tuo tag manager.
Evita grandi aggiornamenti di rendering. Tieni piccolo il DOM, evita il layout forzato e usa il CSS containment per i contenuti fuori dallo schermo.

Come migliorare il CLS: il layout salta

Il CLS non ha unità di misura. Combina quanto contenuto visibile si è spostato e di quanto. Sul campo conta per tutta la visita, ma gli spostamenti entro 500 millisecondi da un’interazione dell’utente restano esclusi. La guida al CLS di web.dev elenca le cause più comuni: immagini senza dimensioni, pubblicità, incorporamenti e iframe senza dimensioni, contenuto inserito dinamicamente e web font. Che cosa aiuta:

Riserva lo spazio. Dai a immagini e video width e height, oppure usa la proprietà CSS aspect-ratio. Per contenuti di dimensione sconosciuta, un min-height sensato è meglio del valore predefinito zero.
Anima con transform. Animare top, left o margin sposta il layout. I banner dei cookie che scivolano dentro sono un caso tipico.
Lascia lavorare la back/forward cache. Ripristina pagine già renderizzate per intero. Gli ostacoli più comuni sono le direttive di cache no-store e i listener dell’evento unload.
Gestisci i web font. font-display: optional, font di ripiego equivalenti con size-adjust e il precaricamento dei font critici riducono gli spostamenti legati ai font.

Come SEOgrinder controlla i Core Web Vitals

SEOgrinder è il nostro strumento: lo costruiamo noi. Inserisci un indirizzo pubblico su SEOgrinder e i numeri di velocità arrivano da Google PageSpeed Insights, per telefono e per desktop. Il riquadro «Core Web Vitals» mostra LCP e CLS dall’esecuzione di laboratorio di Lighthouse e l’INP dai visitatori reali, e un riquadro a parte mostra i dati dei visitatori reali degli ultimi 28 giorni. Se Google ha troppo pochi dati per la pagina, il report lo dice invece di tirare a indovinare. Attività come «I visitatori reali su mobile aspettano … per il contenuto» indicano la metrica, il valore e la correzione. Una risposta lenta del server, che entra nell’LCP, ha un’attività tutta sua.

Limiti: SEOgrinder legge i numeri di Google e non sostituisce il tuo monitoraggio dei visitatori reali. Non misura i posizionamenti. Se la quota giornaliera di Google per la misura della velocità è esaurita, il report arriva senza.

Errori comuni

Fidarsi solo del punteggio di laboratorio. Non può misurare l’INP e può essere diverso da ciò che vivono i visitatori. Parti dai valori dei visitatori reali.
Controllare un solo dispositivo. Mobile e desktop vengono giudicati separatamente.
Caricare in lazy l’immagine principale. loading="lazy" sull’immagine LCP aggiunge ritardo.
Omettere le dimensioni delle immagini. Senza width e height il browser non può riservare lo spazio.
Correggere la parte sbagliata dell’LCP. Comprimi le immagini solo dopo che la scomposizione mostra che il problema è il tempo di caricamento.
Aspettarsi un risultato immediato. I dati sul campo coprono 28 giorni, quindi cambiano gradualmente. Controlla l’esecuzione di laboratorio subito dopo una correzione e i numeri dei visitatori reali nelle settimane successive.

Domande frequenti

Qual è un buon punteggio nei Core Web Vitals?

Non esiste un punteggio unico. Una pagina supera la valutazione quando l’LCP è di 2,5 secondi o meno, l’INP di 200 millisecondi o meno e il CLS di 0,1 o meno al 75° percentile. Il numero da 0 a 100 che forse conosci da Lighthouse è un valore di laboratorio ed è un’altra cosa.

Perché PageSpeed Insights non mostra dati di utenti reali per il mio sito?

Di solito le visite sono troppo poche perché CrUX possa riportare qualcosa. In quel caso web.dev suggerisce di aggiungere una misura tua dei visitatori reali. Fino ad allora, lavora con i valori di laboratorio.

Mi serve un punteggio perfetto?

No. L’obiettivo è superare la valutazione. Google stessa dice che inseguire un punteggio perfetto solo per motivi di SEO potrebbe non essere il modo migliore di usare il tuo tempo.

Il prossimo passo

Analizza la tua pagina più importante con SEOgrinder, apri il riquadro «Core Web Vitals» e guarda prima i valori dei visitatori reali. Correggi l’unica metrica che fallisce, premi Ricontrolla e leggi i valori di laboratorio. Il quadro più ampio è nella nostra checklist audit SEO.