Core Web Vitals nel 2026: metriche attuali
Le metriche attuali sono LCP, INP e CLS. LCP misura il caricamento, INP la reattività e CLS la stabilità visiva. Google le descrive come aspetti centrali dell'esperienza reale degli utenti. [1][3]
FID non fa più parte del set. INP ha sostituito FID nel marzo 2024 e FID è stato poi rimosso dagli strumenti CrUX. [7][14]
Soglie e 75° percentile
| Metrica | Buono | Da migliorare | Scarso | Cosa misura |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Caricamento del contenuto principale |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Reattività delle interazioni |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Stabilità visiva |
I valori buoni sono LCP ≤ 2,5 s, INP ≤ 200 ms e CLS ≤ 0,1. Da migliorare: 2,5-4,0 s, 200-500 ms e 0,1-0,25. Oltre questi limiti il risultato è scarso. [3][4]
Google usa il 75° percentile, non la media. Almeno il 75% delle esperienze deve raggiungere la soglia o fare meglio. Mobile e desktop sono separati. [3][4]
Per passare, tutte e tre le metriche devono essere buone. [3]
Core Web Vitals e SEO
Google conferma che Core Web Vitals viene usato nei sistemi di ranking come parte dell'esperienza di pagina. Buoni valori non garantiscono però una posizione elevata, perché rilevanza e qualità del contenuto restano fondamentali. [1][2]
L'ottimizzazione migliora l'esperienza reale e rimuove una debolezza tecnica, ma non sostituisce la qualità del sito.
LCP: cosa misura davvero
Largest Contentful Paint misura il tempo dall'inizio della navigazione al rendering del più grande elemento di contenuto idoneo nel viewport. Nei dati reali può includere redirect, setup della connessione e TTFB. [5]
LCP non è quindi soltanto il tempo di download dell'immagine più grande. Il ritardo può nascere molto prima del trasferimento della risorsa. [5][6]
LCP nella pratica: quattro sottoparti
web.dev divide LCP in TTFB, ritardo di caricamento della risorsa, durata del caricamento e ritardo di rendering dell'elemento. [6]
Se la risorsa LCP viene scoperta tardi, comprimere il file può non migliorare il risultato. Dovrebbe essere individuabile presto nell'HTML iniziale e un'immagine LCP non dovrebbe usare lazy loading. Priorità o preload possono aiutare. [6]
Diagnostica nell'ordine: TTFB, scoperta della risorsa, trasferimento, ritardo di rendering. [6]
- Riduci TTFB con cache, CDN, meno redirect e backend più veloce.
- Rendi la risorsa LCP disponibile nell'HTML iniziale.
- Non usare `loading="lazy"` sull'immagine LCP.
- Usa priorità adeguata o preload se viene scoperta tardi.
- Ottimizza dimensione e formato solo se il trasferimento è davvero il collo di bottiglia.
- Riduci JavaScript o CSS che blocca il rendering finale.
INP: reattività durante tutta la visita
Interaction to Next Paint osserva click, tap e tastiera lungo l'intera visita. Nella maggior parte delle pagine viene riportata l'interazione più lenta. Con molte interazioni viene ignorata una peggiore interazione ogni 50 per limitare gli outlier. [7]
INP differisce da FID perché include input delay, elaborazione e tempo fino al prossimo paint. [7][8]
Senza click, tap o tastiera, una visita può non avere INP. Scroll e hover non contano. [7]
INP nella pratica: tre fonti di latenza
La latenza totale comprende input delay, processing duration e presentation delay. Un INP scarso può derivare da main thread occupato, handler lenti o layout e rendering costosi. [8]
Le correzioni comuni includono task più brevi, suddivisione del lavoro, meno JavaScript pesante, layout più semplice, Web Workers quando adatti e feedback visivo rapido. [8]
Parti da dati RUM che identificano l'interazione lenta e poi riproducila in DevTools. Lighthouse da solo non rappresenta l'INP reale completo. [8][11][12]
CLS: stabilità per tutta la vita della pagina
Cumulative Layout Shift misura movimenti inattesi degli elementi visibili. Usa la più grande finestra di sessione con spostamenti consecutivi a meno di un secondo di distanza e durata massima di cinque secondi. [9]
CLS è senza unità e combina impatto e distanza dello spostamento. Alcune modifiche direttamente collegate all'azione dell'utente possono essere escluse. [9]
I problemi spesso emergono dopo il caricamento con annunci, banner, widget o font. Un singolo test di laboratorio può non rilevarli. [10][11]
CLS nella pratica: cause comuni
web.dev cita immagini senza dimensioni, annunci, embed e iframe senza spazio riservato, contenuto inserito dinamicamente e web font. [10]
Riserva spazio prima dell'arrivo del contenuto. Usa `width` e `height` o `aspect-ratio`, assegna dimensioni agli slot e non inserire contenuto sopra ciò che l'utente sta leggendo. [10]
Per i font riduci le differenze metriche tra fallback e font finale e misura l'effetto reale. `font-display` da solo non risolve ogni caso. [10]
Dati sul campo contro laboratorio
Core Web Vitals sono principalmente metriche sul campo. CrUX e RUM mostrano utenti reali, Lighthouse aiuta a riprodurre e diagnosticare in condizioni controllate. [11][12]
Lighthouse non misura l'INP completo di una visita naturale e usa metriche come TBT come supporto di laboratorio. Anche CLS può essere più basso in laboratorio se gli spostamenti avvengono dopo interazioni. [11][12]
Usa i dati reali per decidere se esiste un problema e il laboratorio per trovare la causa.
Quale strumento usare
| Strumento | Tipo di dati | Uso migliore |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Valutazione rapida di URL e origin |
| Search Console | CrUX, gruppi di URL | Trovare gruppi di pagine con problemi SEO |
| Chrome DevTools | Laboratorio + contesto CrUX | Diagnosi dettagliata di LCP, INP e CLS |
| Lighthouse | Laboratorio | Audit automatici e regressioni CI |
| RUM / web-vitals | Dati dei propri utenti | Monitoraggio e diagnosi più precisi dopo release |
PageSpeed Insights combina CrUX e Lighthouse. Search Console raggruppa URL simili. DevTools offre metriche live e trace dettagliati. [12][13]
CrUX API e PageSpeed Insights usano una finestra mobile di circa 28 giorni. Una correzione recente non modifica subito il p75 pubblico. RUM proprio è più rapido. [12][13]
Un buon flusso usa RUM per monitorare, Search Console per gruppi SEO, PSI per controlli rapidi e DevTools per diagnosi.
CrUX nel 2026: stato recente del Web
| Metrica | Origin con buon risultato, luglio 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Tutti i Core Web Vitals | 55,7% |
L'ultimo dataset mensile pubblicato prima del 4 settembre 2026 riguarda luglio 2026 ed è stato pubblicato l'11 agosto. Include 18.059.068 origin. Il 68,3% aveva buon LCP, l'81,6% buon CLS, l'85,7% buon INP e il 55,7% passava tutti i Core Web Vitals. [14]
Sono dati aggregati del Web rappresentato in CrUX, non obiettivi per il singolo sito. CrUX include solo pagine e origin idonei, tra cui pubblicamente individuabili e sufficientemente popolari. [13][14]
L'assenza di dati CrUX non significa prestazioni buone o cattive.
SPA e soft navigations: cambiamento importante nel 2026
Storicamente Core Web Vitals era centrato sulle navigazioni complete. Chrome 151 ha introdotto nel 2026 nuove API per misurare le soft navigations e la documentazione è stata aggiornata il 2 settembre 2026. [15]
Chrome DevTools 152, rilasciato il 25 agosto 2026, mostra queste metriche in Live Metrics per impostazione predefinita usando `web-vitals` 6.0.0. [16]
È importante per React, Angular, Vue e altre SPA. Non bisogna però assumere che tutti i report pubblici CrUX trattino già le soft navigations nello stesso modo.
Monitoraggio in produzione con contesto
Un p75 pubblico dice spesso che esiste un problema senza mostrarne la causa. RUM proprio può allegare elemento e sottoparti LCP, interazione INP, route, dispositivo e versione app. web.dev raccomanda RUM come complemento di CrUX. [3][8][12]
Versiona i deploy e confronta distribuzioni prima e dopo. La media può nascondere regressioni sui dispositivi più lenti.
CI protegge da regressioni evidenti di laboratorio, ma non sostituisce il monitoraggio in produzione. [11][12]
Piano pratico di miglioramento
Identifica prima quale metrica fallisce al p75 e su quali tipi di pagina. Restringi il problema con RUM o CrUX, riproducilo in DevTools, correggi la causa specifica e monitora dopo il deploy. [12]
Per LCP trova la sottoparte dominante, per INP l'interazione davvero lenta e per CLS gli spostamenti specifici.
Controlla poi dati di laboratorio e reali. CrUX pubblico richiede tempo per riflettere una nuova release, quindi RUM è prezioso per una verifica rapida.
- Individua il problema prima nei dati reali.
- Separa mobile e desktop.
- Per LCP analizza TTFB, scoperta, trasferimento e ritardo di rendering.
- Per INP analizza l'interazione e le sue tre fasi.
- Per CLS registra gli spostamenti durante tutta la sessione.
- Rilascia una correzione misurabile e confronta prima e dopo.
- Mantieni RUM e alert di regressione attivi.
