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

Di Daniele Forciniti

Indice del Contenuto

I Core Web Vitals sono tre misure con cui Google valuta l’esperienza reale di chi visita una pagina: l’LCP misura quanto tempo serve per vedere il contenuto principale, l’INP quanto la pagina è pronta a rispondere a clic e tocchi, il CLS quanto si sposta mentre la stai usando. Nel 2026 le soglie sono sempre le stesse: LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1, calcolati sui dati veri dei visitatori che usano Chrome. Contano per il posizionamento, ma meno di quanto si legge in giro: Google li usa tra i suoi segnali, però una pagina più utile resta davanti a una più veloce.

Perché se ne parla ancora (e cosa non è cambiato)

Ogni anno escono articoli che annunciano una rivoluzione: soglie più severe, un punteggio unico, metriche nuove. Nel 2026 non è successo niente di tutto questo. Ho controllato la documentazione ufficiale e le metriche sono ancora tre, con gli stessi valori. Su web.dev Google spiega anche come funzionano le modifiche: una metrica nuova passa prima per una fase sperimentale, poi resta “in attesa” per almeno sei mesi, e le metriche stabili non cambiano più di una volta l’anno. Una novità improvvisa, annunciata solo da qualche blog, va presa con molta prudenza.

L’ultimo cambiamento vero risale al 12 marzo 2024, quando l’INP ha preso il posto del FID (First Input Delay). Molte guide in italiano e in spagnolo, anche tra le prime su Google, parlano ancora del FID: se ne trovi una così, è vecchia di almeno due anni.

Le metriche di velocità sono una delle parti più tecniche della gestione SEO del sito, ma anche una delle più frequentate da miti. Qui provo a separare quello che dice Google da quello che si ripete per abitudine.

LCP, INP e CLS spiegati in modo semplice

Le soglie di LCP, INP e CLS: valori buoni, da migliorare e scadenti secondo Google

LCP: quando vedi il contenuto principale

Il Largest Contentful Paint misura il tempo che passa da quando apri la pagina a quando compare l’elemento più grande nella parte visibile dello schermo. Di solito è l’immagine principale, un video o un blocco di testo grande, come il titolo. È il momento in cui chi visita ha la sensazione che la pagina sia arrivata. Il valore buono è entro 2,5 secondi.

INP: quanto risponde la pagina quando la usi

L’Interaction to Next Paint misura quanto tarda la pagina a mostrare una reazione dopo un clic, un tocco o un tasto premuto. Non conta solo la prima interazione, come faceva il FID, ma tutte quelle della visita, e prende la più lenta (scartando i casi anomali). Pensa al menu che si apre in ritardo o al pulsante “aggiungi al carrello” che sembra non funzionare: quello è un INP alto. Il valore buono è entro 200 millisecondi.

CLS: quanto si sposta la pagina

Il Cumulative Layout Shift misura gli spostamenti improvvisi degli elementi mentre la pagina si carica o mentre la usi. È il caso classico del testo che scende perché sopra è comparso un banner, o del pulsante che si sposta proprio mentre stai per toccarlo. Non è un tempo ma un punteggio: zero vuol dire nessuno spostamento, e il valore buono è entro 0,1.

Metrica	Cosa misura	Buono	Da migliorare	Scadente
LCP	Caricamento del contenuto principale	fino a 2,5 s	fino a 4 s	oltre 4 s
INP	Risposta a clic, tocchi e tasti	fino a 200 ms	fino a 500 ms	oltre 500 ms
CLS	Spostamenti imprevisti del layout	fino a 0,1	fino a 0,25	oltre 0,25

Un dettaglio che molti non sanno: per superare la valutazione bisogna essere nel verde in tutte e tre. Il report di Search Console assegna a ogni gruppo di pagine lo stato della metrica peggiore, quindi un LCP perfetto non compensa un CLS scadente.

Quanto contano davvero per il posizionamento

Qui conviene leggere le parole di Google, perché sono più misurate di quanto si pensi. Nella pagina sull’esperienza della pagina, aggiornata a settembre 2026, Google conferma che queste metriche sono usate dai suoi sistemi di ranking. Subito dopo però aggiunge che avere buoni risultati nel report di Search Console o negli strumenti di terze parti non garantisce di arrivare in cima, e che inseguire un punteggio perfetto solo per la SEO potrebbe non essere il modo migliore di usare il tempo.

In pratica funziona così:

La pertinenza viene prima. Google scrive che mostra sempre il contenuto più utile, anche quando l’esperienza della pagina non è buona.
A parità di contenuto, la velocità aiuta. Quando per una ricerca ci sono tante pagine valide, un’esperienza migliore può fare la differenza.
Non esiste un unico “segnale esperienza”. Google guarda più aspetti insieme: oltre alle tre metriche, la sicurezza HTTPS, la resa su telefono, la quantità di pubblicità e i popup invadenti.
La valutazione è per pagina, ma Google ammette di avere anche alcune valutazioni sull’intero sito.

Il motivo vero per occuparsene, secondo me, non è il ranking: è che una pagina lenta o instabile fa scappare le persone prima che leggano o comprino qualcosa. Il vantaggio SEO arriva quasi di conseguenza.

Dati reali e test di laboratorio: perché i numeri non coincidono

È la domanda che mi fanno più spesso: “PageSpeed mi dà 45 su 100, ma Search Console dice che va tutto bene. Chi ha ragione?”. Di solito tutti e due, perché misurano cose diverse.

I dati sul campo vengono dal Chrome UX Report (CrUX): sono le misure anonime raccolte da Chrome sulle visite vere degli ultimi 28 giorni. Google prende il 75° percentile, cioè il valore che rispetta almeno tre visite su quattro, separato tra mobile e computer. Sono questi i dati che contano per Google.
I dati di laboratorio vengono da Lighthouse: un test simulato, fatto una volta sola con un telefono e una connessione di riferimento. Il punteggio da 0 a 100 che vedi su PageSpeed Insights viene da qui. Serve per trovare i problemi, ma non è quello che Google usa per valutare il sito.

C’è anche un limite pratico: se il sito ha poche visite, CrUX non ha abbastanza dati e Search Console mostra “Nessun dato disponibile”. Succede spesso ai siti piccoli e nuovi. In quel caso si lavora con i test di laboratorio, sapendo che sono solo un’indicazione.

Come misurarli: gli strumenti gratuiti

Strumento	Tipo di dati	A cosa serve
Search Console, report Core Web Vitals	Campo (CrUX)	Vedere quali gruppi di pagine hanno problemi, su mobile e computer
PageSpeed Insights	Campo e laboratorio	Controllare una singola pagina e ricevere i suggerimenti tecnici
Lighthouse	Laboratorio	Fare test ripetuti mentre si correggono i problemi
Chrome DevTools, pannello Performance	Laboratorio, sul tuo browser	Trovare l’elemento LCP, le interazioni lente e gli spostamenti
Chrome UX Report	Campo	Analisi più avanzate e storiche, anche per paese

Il mio ordine di lavoro è sempre lo stesso. Parto dal report di Search Console, che fa parte dei report da controllare ogni mese, e guardo prima il mobile. Ogni riga è un gruppo di pagine simili: apro un URL di esempio, lo passo su PageSpeed Insights e leggo prima la parte con i dati reali, poi i suggerimenti del test. Quando ho corretto, nel report clicco su “Avvia monitoraggio”: Google controlla il problema per 28 giorni sui dati nuovi.

Come sta il web: i numeri del 2025

Percentuale di siti con LCP, INP e CLS buoni su mobile e computer secondo il Web Almanac 2025

Il Web Almanac 2025 di HTTP Archive ha analizzato i dati di Chrome su milioni di siti. Il risultato è utile per capire dove si sbaglia di più:

Solo il 48% dei siti su mobile supera tutte e tre le soglie (il 56% su computer). Nel 2023 su mobile era il 36%.
L’LCP è il punto debole: su mobile è buono nel 62% dei siti, contro il 74% su computer.
L’INP va molto meglio su computer (97% di siti buoni) che su telefono (77%), perché i telefoni hanno meno potenza per eseguire il JavaScript.
Il CLS è l’unico migliore su mobile: 81% di siti buoni, contro il 72% su computer.
Le immagini sono l’elemento LCP nel 76% delle pagine mobile, e circa il 16% delle pagine carica quell’immagine in modo “pigro” (lazy loading), cioè la fa arrivare più tardi.
Il 62% delle pagine mobile ha almeno un’immagine senza dimensioni impostate, una delle cause più comuni degli spostamenti.

Tradotto: se il tuo sito non supera la valutazione su mobile sei in buona compagnia, ma è anche un’occasione. Le correzioni che servono sono spesso semplici.

Come migliorare l’LCP

Google ha raccolto in una guida le correzioni che funzionano meglio. Per l’LCP le più utili sono queste:

Non caricare in modo pigro l’immagine principale. Il lazy loading va bene per le immagini più in basso, non per quella in cima alla pagina. Molti temi e plugin lo applicano a tutte.
Dai priorità all’immagine principale con l’attributo fetchpriority=”high”, così il browser la scarica prima delle altre risorse.
Fai trovare l’immagine subito nell’HTML. Se l’immagine principale è un’immagine di sfondo in CSS o viene inserita dal JavaScript, il browser la scopre tardi.
Alleggerisci le immagini: dimensioni giuste per lo schermo e formati moderni come WebP o AVIF. Secondo il Web Almanac il 57% delle immagini LCP è ancora in JPG.
Riduci il tempo di risposta del server con una buona cache e, se hai visite da più paesi, con una CDN.

Come migliorare l’INP

L’INP dipende quasi sempre dal JavaScript: quando il browser è occupato a eseguire codice, non può rispondere al clic. Le correzioni principali:

Togli il JavaScript che non serve. Plugin non usati, script di chat, mappe e strumenti di marketing caricati su tutte le pagine anche dove non servono.
Spezza i compiti lunghi. Un’operazione che blocca il browser per più di 50 millisecondi si chiama compito lungo: va divisa in parti più piccole, così il browser ha il tempo di rispondere tra una e l’altra.
Mostra subito una reazione. Quando una persona clicca, aggiorna prima la parte visibile (un menu che si apre, un pulsante che cambia stato) e rimanda il lavoro pesante a dopo.
Attento agli script di terze parti come pixel pubblicitari e strumenti di analisi: spesso sono loro a rallentare le interazioni, e non si vedono nel codice del sito.

Come migliorare il CLS

Imposta larghezza e altezza su immagini, video e iframe, così il browser riserva lo spazio prima che arrivino.
Riserva lo spazio per banner, pubblicità e avvisi cookie invece di inserirli sopra il contenuto quando la pagina è già visibile.
Gestisci i caratteri web: un font che arriva tardi e ha misure diverse da quello di riserva fa “saltare” il testo.
Anima solo trasformazioni e trasparenze, non altezza, larghezza o posizione, che costringono il browser a ricalcolare la pagina.
Rendi le pagine compatibili con la cache avanti/indietro (bfcache): quando torni indietro, la pagina riappare all’istante e senza spostamenti.

Su WordPress e Wix cosa puoi fare

Su WordPress hai molto controllo, e quindi molte occasioni di sbagliare. Le cause che trovo più spesso sono un tema pesante, un page builder che carica tutto su ogni pagina e troppi plugin. Un plugin di cache e uno per ottimizzare le immagini aiutano, ma non risolvono un tema fatto male: a volte la correzione vera è proprio rifare il tema, come faccio nello sviluppo di siti WordPress.

Su Wix il server, la cache e la CDN sono gestiti dalla piattaforma, quindi su quella parte non puoi intervenire. Puoi però lavorare su quello che metti nella pagina: immagini leggere, meno animazioni, meno app esterne e meno codice incorporato. Spesso un sito Wix lento è lento per gli elementi aggiunti, non per la piattaforma.

Gli sbagli più comuni

Quando analizzo i siti di piccole e medie aziende, ritrovo quasi sempre gli stessi problemi:

Inseguire il 100 su PageSpeed e ignorare i dati reali di Search Console, che sono quelli che contano.
Guardare solo il computer. La maggior parte delle visite arriva da telefono, e lì i risultati sono quasi sempre peggiori.
Uno slider con cinque immagini grandi in cima alla home, che rende lento l’LCP.
Il banner dei cookie o una barra promozionale che spinge giù tutta la pagina.
Plugin di “ottimizzazione” uno sopra l’altro, che a volte rompono il sito o peggiorano l’INP.
Correggere e non convalidare: senza avviare il monitoraggio in Search Console non sai se la correzione ha funzionato sui dati veri.

Il mio parere

Faccio siti e posizionamento da più di dieci anni, e ho visto la velocità passare da dettaglio tecnico a tema da riunione. A volte troppo: ho visto aziende spendere settimane per portare PageSpeed da 85 a 98, mentre le pagine servizio non rispondevano alle domande dei clienti. È tempo speso male, e Google stesso lo dice.

Il punto giusto, per me, è questo: superare le tre soglie su mobile e poi fermarsi, salvo casi particolari come gli e-commerce con molte visite, dove ogni decimo di secondo pesa sulle vendite. Una volta nel verde, il tempo rende di più se lo metti sui contenuti e sui collegamenti. Se vuoi un controllo del tuo sito fatto con questo criterio, rientra nei miei servizi SEO.

In sintesi

LCP, INP e CLS misurano tre cose semplici: quanto presto vedi la pagina, quanto presto risponde e quanto resta ferma. Nel 2026 le soglie sono ancora 2,5 secondi, 200 millisecondi e 0,1, e contano i dati reali dei visitatori, non il punteggio di un test. Google li usa per il posizionamento, ma la pertinenza viene prima. Controlla il report su mobile in Search Console, correggi le cause più comuni (immagini, JavaScript, spazi non riservati) e, una volta nel verde, torna a lavorare sui contenuti.

FAQ

Cosa sono LCP, INP e CLS?

Sono le tre metriche con cui Google misura l’esperienza su una pagina. L’LCP misura il caricamento del contenuto principale, l’INP la velocità di risposta a clic e tocchi, il CLS la stabilità della pagina durante il caricamento e l’uso.

Quali sono le soglie nel 2026?

Sono le stesse degli ultimi anni: LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS entro 0,1. Si calcolano sul 75° percentile delle visite reali degli ultimi 28 giorni, separatamente per mobile e computer.

Il FID esiste ancora?

No. Dal 12 marzo 2024 il FID è stato sostituito dall’INP, che misura tutte le interazioni della visita e non solo la prima. Gli strumenti di Google non lo mostrano più.

Un punteggio basso su PageSpeed Insights mi fa perdere posizioni?

Non direttamente. Il punteggio da 0 a 100 viene da un test di laboratorio. Google usa i dati reali dei visitatori, che trovi nella parte alta di PageSpeed Insights e nel report di Search Console.

Perché Search Console dice “Nessun dato disponibile”?

Perché le pagine non hanno abbastanza visite da Chrome per avere dati affidabili, oppure la proprietà è stata creata da poco. Nel primo caso puoi usare i test di laboratorio come indicazione.

Quanto tempo serve per vedere i miglioramenti in Search Console?

I dati reali coprono gli ultimi 28 giorni, quindi un miglioramento si vede del tutto solo dopo circa quattro settimane. Anche il monitoraggio che avvii nel report dopo una correzione dura 28 giorni.

I siti lenti vengono penalizzati da Google?

Non esiste una penalizzazione per i siti lenti. Le metriche sono uno dei segnali di ranking: possono aiutare una pagina quando ci sono altre pagine ugualmente utili, ma non scavalcano la pertinenza del contenuto.

Fonti

Google Search Central, Core Web Vitals e risultati di ricerca: le tre metriche e le soglie ufficiali.
Google Search Central, esperienza sulla pagina: come le metriche entrano nel ranking e i loro limiti.
Guida di Search Console, report Core Web Vitals: stati, gruppi di URL e dati sul campo.
web.dev, Web Vitals e l’annuncio dell’INP: ciclo di vita delle metriche e passaggio dal FID all’INP.
web.dev, le correzioni più efficaci: le raccomandazioni di Google per LCP, INP e CLS.
HTTP Archive, Web Almanac 2025, capitolo Performance: i dati reali sui siti nel 2025.

Daniele Forciniti

Sono Daniele Forciniti, un esperto di web design e SEO con oltre 10 anni di esperienza e diverse certificazioni professionali. Mi specializzo in HTML e CSS, utilizzo CMS come WordPress. Sono il maggior esperto in Italia di WIX e WIX Studio, mi occupo anche di SEO posizionamento web nei motori di ricerca e digital marketing. Sono appassionato del mio lavoro e continuo ad aggiornare le mie competenze per fornire soluzioni innovative e di alta qualità ai miei clienti.