Core Web Vitals 2026: guida pratica all'ottimizzazione
LCP, INP e CLS spiegati in modo semplice, con le novità del 2026 e strategie concrete per rendere il tuo sito più veloce e più stabile.
Dal 2021 Google usa i Core Web Vitals come segnale di ranking all'interno della «page experience». Le metriche sono tre e le soglie non sono cambiate: quello che è cambiato nel 2026 è soprattutto il modo in cui vengono misurate. Vediamo cosa misurano, cosa c'è di nuovo e come migliorarle in modo concreto.
Le tre metriche fondamentali
LCP — Largest Contentful Paint
Misura quanto tempo serve perché l'elemento più grande visibile nella pagina (di solito l'immagine principale o un blocco di testo) venga mostrato. Obiettivo: entro 2,5 secondi. Tra 2,5 e 4 secondi è «da migliorare», oltre è «scarso».
INP — Interaction to Next Paint
Ha sostituito FID nel marzo 2024. Misura la reattività: quanto tempo passa tra un'interazione (clic, tocco, digitazione) e il momento in cui la pagina mostra una risposta visiva. Obiettivo: entro 200 millisecondi. A differenza di FID, considera tutte le interazioni della visita, non solo la prima.
CLS — Cumulative Layout Shift
Misura la stabilità visiva: quanto si spostano gli elementi mentre la pagina si carica. Testo che salta, pulsanti che cambiano posizione proprio mentre stai per toccarli. Obiettivo: sotto 0,1.
Per superare la valutazione, Google guarda il 75° percentile delle visite reali: almeno tre visite su quattro devono restare entro la soglia, separatamente su mobile e su desktop.
Cosa cambia nel 2026
La novità principale riguarda i siti costruiti come single-page application (React, Vue, Angular e simili). Fino a oggi, quando si cambiava pagina senza ricaricare il documento, il browser continuava ad attribuire le metriche all'URL iniziale. Da Chrome 151, rilasciato ad agosto 2026, queste «soft navigation» vengono misurate di default: ogni cambio di pagina ha i propri LCP, INP e CLS.
Due precisazioni. Google non ha ancora stabilito come queste misure confluiranno nel Chrome UX Report, la base dati usata da PageSpeed Insights e da Search Console. E le soglie restano quelle di sempre: in rete circolano articoli su un LCP «abbassato a 2 secondi» o su una valutazione «per dominio», ma la documentazione ufficiale di Google non riporta nulla del genere.
Le cause più comuni di un LCP alto
- Immagine principale pesante o senza fetchpriority="high"
- Immagine principale caricata in lazy loading: sopra la piega va evitato
- Font caricati da servizi esterni, in modo bloccante
- TTFB alto: server lento, nessuna cache, CDN assente
- CSS e JavaScript che bloccano il rendering nel <head>
- Immagini in JPEG o PNG dove WebP o AVIF peserebbero molto meno
Come migliorare LCP
L'intervento più efficace è quasi sempre sull'immagine principale: un formato moderno (WebP o AVIF), dimensioni adatte allo schermo tramite srcset, fetchpriority="high" e niente lazy loading. Se l'immagine è definita nel CSS, un <link rel="preload"> nel <head> permette al browser di scoprirla subito.
Seconda priorità: il server. Una pagina che arriva dopo 1,5 secondi ha già consumato più di metà del tempo a disposizione. Cache delle pagine, compressione e una CDN riducono il TTFB più di qualsiasi ottimizzazione del front-end. Infine, ospitare i font sullo stesso dominio elimina una connessione esterna, particolarmente costosa sulle reti mobili.
Come migliorare INP
INP è spesso la metrica più difficile, perché dipende da quanto JavaScript il browser esegue sul thread principale. Le strategie che funzionano:
- Ridurre gli script di terze parti (chat, widget, pixel pubblicitari) e caricarli solo dove servono
- Spezzare i task lunghi, restituendo il controllo al browser con scheduler.yield() dove è supportato e setTimeout come alternativa
- Mostrare subito un riscontro visivo dell'interazione e rimandare il lavoro pesante
- Caricare gli script non critici con defer o async
- Evitare DOM enormi: pagine con migliaia di nodi rendono lento ogni aggiornamento
Come migliorare CLS
CLS è in genere il più semplice da risolvere. La maggior parte dei problemi nasce da:
- Immagini e video senza width e height: il browser non riserva lo spazio
- Font web che, caricandosi, cambiano le dimensioni del testo: font-display: swap aiuta, ma per eliminare lo spostamento serve un font di riserva con metriche simili (size-adjust)
- Banner, annunci e widget inseriti senza uno spazio riservato
- Contenuti aggiunti dinamicamente sopra quelli già visibili
In un audit su un sito cliente abbiamo ridotto il CLS da 0,42 a 0,02 semplicemente aggiungendo width e height espliciti a tutte le immagini e sistemando il caricamento dei font.
Strumenti per misurare
PageSpeed Insights resta il punto di partenza, ma mostra due cose diverse: i dati di laboratorio (una simulazione) e i dati reali degli utenti di Chrome negli ultimi 28 giorni. Per la valutazione di Google contano i secondi. Il report Core Web Vitals di Search Console raggruppa le pagine con problemi simili, mentre il pannello Performance di Chrome DevTools è indispensabile per capire quale interazione causa un INP alto. Per un monitoraggio continuo, la libreria web-vitals permette di raccogliere le metriche direttamente dagli utenti reali.
Conclusione
I Core Web Vitals non sono solo metriche di ranking: sono un indicatore dell'esperienza reale di chi visita il sito. Un sito veloce e stabile converte meglio e trattiene di più. E l'ottimizzazione non si fa una volta sola: va tenuta sotto controllo nel tempo, soprattutto dopo ogni rilascio o aggiornamento dei contenuti.