Core Web Vitals 2026: cosa muove ancora il posizionamento

Quasi tutte le richieste su questo tema iniziano con una barra rossa in PageSpeed Insights e con la domanda su quanto costi sistemarla. La risposta dipende da tre cose: se per quella pagina esistano dati di campo, quali template siano coinvolti e se i suoi contenuti reggano il confronto con i risultati che oggi la precedono.

Qui trova l'ordine con cui affrontiamo il lavoro e i punti in cui ci fermiamo di proposito. La parte esplicativa su LCP, INP e CLS l'ha scritta Google, con più profondità di quanta ne possa avere il riassunto di un'agenzia. I riferimenti sono in fondo.

Cosa decidono davvero i Core Web Vitals

Google non descrive la page experience come un segnale unico. La documentazione di Search Central dice che i sistemi di ranking guardano a una varietà di segnali coerenti con la page experience complessiva. I Core Web Vitals sono uno di questi.

Nello stesso documento ci sono due frasi che raramente arrivano nelle presentazioni delle agenzie. Un buon risultato nel report Core Web Vitals di Search Console non garantisce che le sue pagine si posizionino in cima. E cercare un punteggio perfetto per soli motivi SEO, testualmente, potrebbe non essere il modo migliore di impiegare il suo tempo. Alla domanda su quanto pesi la page experience per il posizionamento, la documentazione risponde che la Ricerca mostra comunque i contenuti più pertinenti, anche quando la page experience è scadente.

Da qui esce una regola pratica utilizzabile. Se una pagina sta in posizione 30, quasi certamente il problema non è l'LCP. Se sta in posizione 4 e i tre risultati sopra sono equivalenti per sostanza, la qualità tecnica può fare la differenza. Poi c'è la parte che vale a prescindere da Google: le pagine lente costano richieste di contatto, e quella parte la può calcolare nel suo analytics senza speculare sulle posizioni.

Le tre metriche e cosa significa "buono"

Dal 12 marzo 2024 Interaction to Next Paint (INP) è un Core Web Vital stabile e ha sostituito First Input Delay. Chrome ha poi rimosso FID: dal 9 settembre 2024 gli strumenti Chrome non forniscono più dati FID. Una dashboard ancora impostata su FID misura il nulla da oltre un anno.

Le soglie di Google per "buono":

La precisazione che quasi tutti i riassunti tagliano conta più dei numeri: la misura avviene al 75esimo percentile delle visualizzazioni, separando mobile e desktop. Una pagina è considerata superata solo se tiene tutte e tre le soglie a quel percentile. Il test che fa lei dal MacBook sulla wifi dell'ufficio, quindi, non è una misura: è un singolo punto preso dalla parte comoda della distribuzione.

Vale anche il contrario. Se il 30 per cento dei suoi utenti ha un'esperienza pessima, la pagina non passa, per quanto il valore medio possa sembrare accettabile. Il 75esimo percentile è una scelta deliberata: protegge la coda lenta, non la media.

Dati di campo o dati di laboratorio

I dati di campo vengono dal Chrome User Experience Report (CrUX): utenti Chrome reali, aggregati su una finestra di 28 giorni. PageSpeed Insights, il report Core Web Vitals di Search Console e l'API CrUX attingono tutti da lì.

I dati di laboratorio vengono da Lighthouse: un dispositivo, un profilo di rete, una posizione geografica, una singola esecuzione. Riproducibile, e per questo utile a isolare un problema, ma resta una simulazione.

Lighthouse non misura l'INP

Senza un'interazione reale non esiste un valore INP. Non è una lacuna dello strumento, è una proprietà della metrica. In laboratorio il sostituto è il Total Blocking Time. Un TBT verde insieme a un INP pessimo non è una contraddizione: è il caso normale, tipico dei siti in cui l'utente interagisce molto dopo il caricamento.

CrUX non vede tutto

Chrome su iOS, le WebView Android e gli altri browser Chromium come Edge non contribuiscono ai dati. I parametri di query e i frammenti vengono rimossi dall'URL, quindi tutte le varianti confluiscono in un unico valore. Per uno shop con URL filtrati questo produce aggregazioni che nessuno si aspetta.

Quando campo e laboratorio non concordano

Vince il campo. Lo scrive la documentazione Chrome: i dati di campo rappresentano quello che gli utenti sperimentano davvero e sono la base su cui dare priorità al lavoro. Il laboratorio resta utile per capire il perché, non per decidere il cosa.

Il problema italiano: spesso i dati di campo non ci sono

CrUX include una pagina solo se è indicizzabile e raggiunge un numero minimo di visitatori. Google non pubblica quella soglia, dice soltanto che è la stessa per pagine e origini ed è tarata per avere abbastanza campioni.

Per gran parte delle aziende con cui lavoriamo in Alto Adige e nel Nord Italia questo significa una cosa concreta: a livello di singola pagina i dati di campo non esistono. Restano, se va bene, i dati a livello di origine per l'intero dominio.

C'è un fattore che peggiora la situazione e riguarda proprio questo mercato. Un sito bilingue italiano e tedesco distribuisce lo stesso traffico su due set di URL. Se poi si aggiunge l'inglese, i set diventano tre. Il traffico totale non cambia, ma quello per singola pagina si divide, e la soglia CrUX si valuta per pagina. Una pagina a basso traffico può quindi restare fuori dal dataset anche quando l'origine dispone di dati.

Quando succede, ci sono due strade e nessuna scorciatoia. La prima è lavorare a livello di origine, accettando che il valore descriva il dominio e non la pagina. La seconda, quella che consigliamo, è misurare in proprio: la libreria web-vitals di Google Chrome raccoglie LCP, INP e CLS dagli utenti reali e li invia al suo analytics. Due settimane di raccolta bastano per avere una base di partenza credibile.

Senza dati di campo si ottimizza contro una simulazione. È il modo più veloce per spendere ore su un problema che i suoi utenti non hanno.

L'ordine in cui interveniamo

Nessuno paga perché vengano spuntati quaranta suggerimenti di Lighthouse in fila. La sequenza che seguiamo nel lavoro tecnico on-page:

1. Dati di campo prima di ogni modifica. Se non ci sono, si installa il monitoraggio reale e si raccolgono due settimane. Senza un valore di partenza non si potrà dimostrare che cosa ha prodotto il lavoro.
2. Aggregare per tipo di pagina, non per singolo URL. Home, pagina servizio, categoria, prodotto, articolo. Una correzione sul template vale per mille URL, una correzione sull'URL vale per uno. Google valuta pagina per pagina, ma si ripara il template.
3. Dare priorità al valore commerciale, non al punteggio. Il template che genera richieste viene per primo, anche se un altro ha numeri peggiori.
4. Prima l'LCP, e in quest'ordine: identificare l'elemento LCP, verificare che il suo URL sia individuabile nel sorgente HTML, poi impostare la priorità (fetchpriority="high", togliere loading="lazy" dall'immagine LCP), poi TTFB e CDN, e solo alla fine il peso del file.
5. Poi il CLS, perché di solito costa poco: width e height oppure aspect-ratio su tutto ciò che carica in ritardo. Un min-height sensato al posto dell'altezza predefinita di 0 pixel per i contenitori il cui contenuto arriva dopo. Nessuna animazione su proprietà che innescano il layout, si usa transform. Poi si verifica l'idoneità alla bfcache, che aiuta anche l'LCP.
6. L'INP per ultimo e solo con diagnostica di campo. Spezzare i task lunghi (tutto ciò che supera i 50 millisecondi), togliere il JavaScript inutile, evitare aggiornamenti di rendering pesanti. Il container del tag manager va messo sul tavolo qui, perché è lì che finiscono gli script di cui internamente non risponde più nessuno.
7. Aspettare 28 giorni. La finestra CrUX è scorrevole: una correzione appare prima come miglioramento piatto ed è pienamente visibile solo dopo quattro settimane.

Il passo 7 è quello su cui i progetti si arenano, perché dopo dieci giorni qualcuno chiede perché non sia cambiato nulla.

LCP: l'errore che vediamo più spesso

Vale la pena soffermarsi sul punto 4, perché è dove si spreca più tempo.

L'istinto, davanti a un LCP lento, è comprimere l'immagine. Nei dati reali analizzati da Chrome, però, la maggior parte delle origini con LCP scadente impiega meno del 10 per cento del proprio tempo LCP al 75esimo percentile per scaricare effettivamente l'immagine. Il tempo si perde prima: il browser scopre tardi quale risorsa gli serve.

Succede quando l'URL dell'immagine non compare nella risposta HTML iniziale. Un data-src che richiede JavaScript, un rendering lato client che costruisce l'immagine dopo l'esecuzione dello script, uno sfondo dichiarato in un CSS esterno: in tutti questi casi lo scanner di precaricamento del browser non può vedere nulla e resta fermo. Un'immagine più leggera che parte tardi arriva comunque tardi.

Il controllo pratico dura un minuto. Apra il sorgente della pagina, non l'ispettore del DOM, e cerchi l'URL dell'immagine principale. Se non c'è, quello è il primo intervento, prima di qualsiasi compressione.

Cosa non ottimizziamo di proposito

Non rincorriamo il punteggio 100 di Lighthouse. È un valore di laboratorio ponderato, non un segnale di ranking.

Non partiamo dalla compressione delle immagini finché l'immagine LCP viene scoperta solo dopo il JavaScript.

E non ottimizziamo template che non hanno né dati di campo né valore commerciale. Un rifacimento del sito è un caso diverso: lì i valori vanno messi nei criteri di collaudo, altrimenti il problema si limita a spostarsi, come capita durante una migrazione SEO più spesso di quanto i clienti si aspettino.

Quando i Core Web Vitals non sono il suo problema

Se il suo sito non compare tra i primi venti risultati per le ricerche che le interessano, passare da 3,4 a 2,1 secondi di LCP non cambierà niente. In quel caso manca contenuto, pertinenza o autorevolezza, e le ore tecniche rendono di più altrove, per esempio nel rendere le sue pagine comprensibili in modo univoco a motori di ricerca e sistemi di IA: Dati strutturati che producono rich result reali.

Se invece i valori sono verdi e le posizioni non arrivano lo stesso, ha escluso una causa in modo pulito. Anche questo è un risultato, e costa meno di un'altra tornata di ipotesi.

---

Se vuole sapere se il collo di bottiglia è davvero tecnico, glielo dice l'analisi gratuita.