Core Web Vitals nel 2026: cosa misurare davvero (e cosa ignorare)

PageSpeed ti dà un voto. Il voto non è la verità. Il voto è la media di pagine lab che a volte ti dicono che vai bene quando i tuoi utenti reali stanno aspettando tre secondi prima di vedere qualcosa. La differenza tra dato di laboratorio e dato di campo è la prima cosa che separa chi misura sul serio.

C'è un rituale che vedo ripetere a Bologna almeno una volta a settimana. L'imprenditore apre PageSpeed, vede 92 su mobile, esulta. Tre mesi dopo si chiede perché il suo sito perde posizioni e converte poco. La risposta semplice, e antipatica, è che il 92 di PageSpeed non significa quello che lui pensava: è una simulazione in laboratorio, fatta su una rete ideale che i suoi clienti non hanno. Quello che Google guarda per il ranking è un'altra cosa, e quella cosa si chiama dato di campo. Capirla cambia tutto, perché ti dice dove guardare per davvero e su quale metrica investire i soldi del tuo sviluppatore.

I Core Web Vitals oggi sono tre. LCP, Largest Contentful Paint: misura in secondi il tempo che impiega l'elemento più grande visibile a comparire sullo schermo. Soglia buona sotto 2.5 secondi, accettabile fino a 4.0, scarsa oltre. INP, Interaction to Next Paint: misura in millisecondi quanto la pagina ci mette a rispondere quando un utente tocca o clicca. Buono sotto 200 ms, accettabile fino a 500, scarso oltre. Ha sostituito il vecchio FID nel 2024 e oggi è la metrica di interattività di riferimento.

CLS, Cumulative Layout Shift: misura quanto la pagina"balla"mentre carica, in una scala senza unità. Sotto 0.1 buono, fino a 0.25 accettabile, oltre scarso. È l'indicatore della frustrazione tipica per cui stai per cliccare un bottone e all'ultimo momento la pagina si sposta e clicchi un'altra cosa.

Google ha scelto queste tre perché coprono i tre momenti che decidono se l'esperienza sembra buona: la prima impressione visiva (LCP), la reattività ai gesti (INP), la stabilità visiva durante il caricamento (CLS). Non sono metriche tecniche fini a sé stesse: sono proxy molto coerenti della frustrazione percepita dagli utenti veri.

Qui sta il punto in cui la maggior parte degli imprenditori si confonde, e dove a volte si confondono anche i tecnici. Lab data: una simulazione fatta dal tool, in condizioni standard, su una pagina specifica. Lighthouse, PageSpeed Insights nella metà superiore, GTmetrix funzionano così. Il dato è ripetibile, comodo per il debug, e non è quello che Google usa per il ranking.

Field data: misurazioni reali raccolte da Chrome sugli utenti veri che hanno visitato il tuo sito negli ultimi 28 giorni. È il dato del CrUX, Chrome User Experience Report, che PageSpeed mostra nella sezione"Scopri come si stanno comportando gli utenti reali". Questo è il numero che Google guarda per i Core Web Vitals come fattore di ranking. È il vero punteggio del tuo sito.

La differenza, in pratica, può essere abissale. Un sito che in laboratorio segna LCP 1.8 secondi su una connessione 4G simulata può avere un LCP reale di 4.5 secondi perché metà dei tuoi utenti naviga su rete 3G affollata da uno smartphone di tre anni fa. Il primo numero ti fa stare tranquillo, il secondo è quello su cui sei valutato. Sempre, sempre, sempre prima il campo, poi il laboratorio per il debug. Il sito che ranka è quello che gira bene sui device veri della tua audience.

L'LCP nella maggior parte dei siti è governato da un solo elemento: l'immagine grande sopra la piega, l'hero. Quando l'LCP è cattivo, nove volte su dieci la colpa è di una hero da 2 MB scaricata da uno stock, in formato JPG, senza dimensioni esplicite, senza preload.

Le leve, in ordine di impatto. Convertire l'hero in WEBP o AVIF e tagliarla a una dimensione ragionevole (sotto i 200 KB, sopra è quasi sempre eccesso). Aggiungere un `<link rel="preload">` nell'head per dire al browser di iniziare a scaricarla subito. Eliminare i font web che bloccano il render: o si caricano in modalità `swap` o si usano i fallback di sistema per il primo paint. Migliorare il tempo di risposta del server: un hosting che impiega 800 ms a rispondere ha già rubato un terzo del tuo budget LCP. Una CDN davanti aiuta, soprattutto se il pubblico è geograficamente disperso.

L'errore tipico: ottimizzare le immagini sotto la piega e ignorare l'hero. Sotto la piega può essere lazy loading, sopra la piega no. Mai mai mai.

INP misura quanto la pagina ci mette a rispondere quando l'utente fa qualcosa. È diventata Core Web Vital ufficiale nel marzo 2024 e ha cambiato la natura del lavoro di performance, perché ora il JavaScript pesante non è più solo un problema generico, è una metrica che pesa sul ranking.

Le cause principali sono tre. JavaScript di app eseguito al caricamento, quando il browser invece dovrebbe rispondere ai tap dell'utente: framework caricati in modalità sbagliata, hydration di Next.js o simili che non è stata ottimizzata, librerie incluse intere quando ne usavi una funzione. Third-party che bloccano il main thread: tag manager pieni di tag mai cancellati, chat live che non usa nessuno, pixel di tracciamento di campagne finite due anni fa. Listener eccessivi su eventi: ogni elemento che ha un suo listener pesante è un punto in cui il tap dell'utente può inchiodare per centinaia di millisecondi.

Le soluzioni più impattanti: pulizia ortodossa dei tag, code splitting del JavaScript, debouncing degli eventi pesanti, valutazione di librerie alternative per i widget più costosi. È un lavoro che vuole un developer che sappia cosa sta facendo, non un plugin"magico"da WordPress.

Il CLS si rompe per pochi motivi precisi e ricorrenti. Immagini senza l'attributo `width` e `height` o senza `aspect-ratio` in CSS, che spingono il contenuto in basso quando si caricano. Font web in modalità swap che cambiano metrica del testo dopo il primo render, spostando tutto. Banner cookie che entrano dall'alto e fanno saltare la pagina. Slot pubblicitari che si riempiono di un annuncio dopo qualche secondo, scaricando il contenuto sotto. Iframe di YouTube o widget di terze parti senza spazio prenotato.

Il fix è banale, e questo è il motivo per cui un CLS rotto è imperdonabile: riservare lo spazio prima, sempre. Dimensioni esplicite su immagini e iframe. Spazio prenotato per i banner cookie e per gli annunci, anche prima che siano caricati. Font con `font-display: swap` ma con un fallback metricamente coerente per evitare lo spostamento. Sono ore di lavoro, non settimane, e la differenza sull'esperienza percepita è enorme.

Vale la pena toglierne dalla testa qualcuno, perché continuano a comparire nei report come se fossero centrali. TTI, Time to Interactive: utile per debug, non è Core Web Vital, non incide sul ranking direttamente. FCP, First Contentful Paint: storicamente importante, oggi superato dall'LCP come metrica primaria. Speed Index: una buona metrica di confronto in laboratorio, irrilevante come fattore di ranking diretto.

Non sono metriche da ignorare in assoluto. Sono metriche da usare per indagare cosa sta succedendo dentro il caricamento, una volta che hai chiaro come stanno LCP, INP, CLS. Confonderle con i Core Web Vitals e ottimizzarle al posto di quelle giuste è il modo più rapido di lavorare senza vedere risultati nei ranking.

L'ordine corretto degli interventi su una pagina lenta è quasi sempre lo stesso. Prima si guarda il campo (CrUX o Search Console sezione Core Web Vitals), per capire qual è la metrica più rotta. Poi si attacca quella con il rapporto costo/beneficio più alto. Per LCP: hero image. Per INP: pulizia di tag manager e JavaScript di terze parti. Per CLS: dimensioni esplicite sulle immagini, spazio per i banner.

I quick win di una giornata di lavoro spostano spesso una pagina da"scarsa"a"accettabile". I lavori più strutturali, hosting, CDN, refactoring del tema WordPress, valgono mesi di rendita ma vogliono un budget reale. Per tutto il resto, esiste un servizio che mette insieme sviluppo del sito, SEO classica e SEO per le AI sotto un solo interlocutore, ed esiste un numero diretto: 329 128 68 25. Una telefonata di dieci minuti, in genere, basta per capire se la tua pagina lenta è un problema da un giorno o da tre settimane. Il resto del contesto lo trovi nella categoria SEO tradizionale.

• Ottimizzazione SEO on-page: la checklist 2026
• Cosa fa davvero un consulente SEO a Bologna