Core Web Vitals: Cosa Sono e Come Ottimizzarli nel 2026

I Core Web Vitals sono un insieme di tre metriche definite da Google per misurare la qualità dell'esperienza utente su un sito web. Si concentrano su tre aspetti fondamentali: velocità di caricamento, reattività alle interazioni e stabilità visiva della pagina durante il caricamento.

Le tre metriche sono LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Insieme, rappresentano il modo in cui Google valuta se un sito offre un'esperienza soddisfacente per chi lo visita.

A marzo 2026, queste metriche sono parte integrante del sistema di ranking di Google. Non sono l'unico fattore che determina il posizionamento, ma incidono in modo misurabile sulla capacità di un sito di competere nelle SERP. Capire cosa misurano, come interpretarle e come ottimizzarle e oggi una competenza necessaria per chiunque si occupi di SEO o gestisca un sito web.

In questa guida analizziamo ogni metrica in dettaglio, con soglie aggiornate, cause comuni di problemi e interventi pratici per migliorare i punteggi. Vedremo anche come misurare i Core Web Vitals con gli strumenti giusti e quanto incidono realmente sul posizionamento.

Cosa sono i Core Web Vitals e perché contano

Google ha introdotto i Core Web Vitals nel 2020 come parte della Page Experience, un insieme di segnali che valutano l'esperienza complessiva offerta da una pagina web. L'obiettivo dichiarato era fornire metriche chiare e misurabili che i proprietari dei siti potessero utilizzare per migliorare l'usabilita delle proprie pagine.

Il concetto alla base è semplice. Gli utenti si aspettano che le pagine carichino velocemente, rispondano immediatamente ai loro input e non si muovano in modo imprevisto durante la navigazione. Quando queste aspettative non vengono soddisfatte, il tasso di abbandono aumenta e la soddisfazione diminuisce.

I dati del Chrome UX Report di febbraio 2026 mostrano che i siti con Core Web Vitals nella fascia "buono" hanno un tasso di rimbalzo inferiore del 24 percento rispetto ai siti con metriche nella fascia "scarso". Questo dato da solo giustifica l'attenzione che Google dedica a queste metriche: correlano direttamente con il comportamento degli utenti.

Le tre metriche sono state scelte perché coprono i tre momenti critici dell'interazione con una pagina. LCP misura la percezione della velocità di caricamento. INP misura la reattività durante tutta la sessione. CLS misura la stabilità del layout. Insieme, offrono un quadro completo della qualità dell'esperienza.

Dal 2024, INP ha sostituito FID (First Input Delay) come metrica di reattività. FID misurava solo il ritardo del primo input, ignorando tutte le interazioni successive. INP è una metrica più completa che considera ogni interazione dell'utente durante l'intera visita, rendendola più rappresentativa della reattività effettiva del sito.

LCP: Largest Contentful Paint

Il Largest Contentful Paint misura il tempo necessario affinché l'elemento di contenuto più grande visibile nel viewport completi il rendering. Questo elemento e tipicamente un'immagine hero, un blocco di testo principale o un video in primo piano. LCP rappresenta il momento in cui l'utente percepisce che la pagina ha "finito di caricarsi".

Soglie LCP

• Buono: entro 2,5 secondi
• Da migliorare: tra 2,5 e 4,0 secondi
• Scarso: oltre 4,0 secondi

Queste soglie si riferiscono al 75esimo percentile delle visite reali degli utenti. Questo significa che il 75 percento dei caricamenti della pagina deve avvenire entro 2,5 secondi per ottenere la valutazione "buono". Non basta che la pagina sia veloce in media: deve esserlo per la grande maggioranza delle visite.

Cause comuni di LCP lento

Il problema più frequente sono le immagini non ottimizzate. Un'immagine hero da 2 MB in formato JPEG, senza lazy loading e senza dimensioni specificate, può da sola portare LCP oltre i 4 secondi su una connessione mobile media. La soluzione e utilizzare formati moderni come WebP o AVIF, specificare width e height, e usare il preload per le immagini above the fold.

I tempi di risposta del server rappresentano un'altra causa comune. Se il server impiega più di 600 millisecondi per rispondere alla prima richiesta (Time to First Byte elevato), LCP ne risente direttamente. L'utilizzo di una CDN, la configurazione corretta della cache e l'ottimizzazione delle query lato server riducono sensibilmente il TTFB.

Il render-blocking di risorse CSS e JavaScript ritarda il rendering del contenuto principale. Fogli di stile non critici e script di terze parti caricati nel head della pagina bloccano il parser del browser. L'inlining del CSS critico, il defer degli script non essenziali e la rimozione di risorse inutilizzate accelerano il rendering.

Ottimizzazione LCP: interventi chiave

1. Servire le immagini in formato WebP o AVIF con compressione adeguata.
2. Aggiungere l'attributo fetchpriority="high" all'immagine LCP.
3. Implementare un preload per la risorsa LCP nel tag head.
4. Ridurre il TTFB sotto i 200 millisecondi tramite CDN e caching lato server.
5. Inlinare il CSS critico above the fold e caricare il resto in modo asincrono.
6. Evitare catene di redirect che aggiungono latenza al caricamento iniziale.

INP: Interaction to Next Paint

L'Interaction to Next Paint misura la reattività complessiva di una pagina alle interazioni dell'utente. A differenza del precedente FID, che registrava solo il ritardo del primo clic o tap, INP considera tutte le interazioni durante l'intera visita: clic, tap su mobile, pressione di tasti sulla tastiera.

INP calcola il tempo che intercorre tra l'azione dell'utente e il momento in cui il browser presenta il prossimo frame aggiornato sullo schermo. Include tre fasi: il ritardo prima che il gestore dell'evento inizi a eseguirsi (input delay), il tempo di esecuzione del gestore (processing time) e il tempo necessario al browser per dipingere il frame aggiornato (presentation delay).

Soglie INP

• Buono: entro 200 millisecondi
• Da migliorare: tra 200 e 500 millisecondi
• Scarso: oltre 500 millisecondi

La metrica riportata è il valore al 75esimo percentile di tutte le interazioni osservate durante la visita. Google sceglie l'interazione più lenta (o quasi: per visite con molte interazioni usa un'approssimazione statistica) come valore rappresentativo. Se anche una sola interazione critica e lenta, il punteggio INP ne risente.

Cause comuni di INP alto

La causa principale e l'esecuzione di JavaScript pesante sul thread principale del browser. I cosiddetti "long task", attività JavaScript che durano più di 50 millisecondi, bloccano il thread principale e impediscono al browser di rispondere agli input dell'utente. Script di analytics, widget di terze parti e framework JavaScript mal configurati sono i responsabili più frequenti.

Un'altra causa comune e l'uso eccessivo di event handler complessi. Gestori di eventi che eseguono calcoli pesanti, manipolano il DOM in modo massiccio o effettuano chiamate di rete sincrone rallentano la risposta del browser alle azioni dell'utente. L'ottimizzazione richiede di spezzare il lavoro in task più piccoli usando requestIdleCallback o setTimeout per cedere il controllo al browser.

Ottimizzazione INP: interventi chiave

1. Identificare e spezzare i long task usando il Performance Panel di Chrome DevTools.
2. Usare requestIdleCallback o scheduler.yield per cedere il thread principale.
3. Caricare gli script di terze parti con defer o async e ritardare quelli non critici.
4. Ridurre la complessità dei gestori di eventi: evitare manipolazioni DOM pesanti.
5. Usare web worker per calcoli complessi che non richiedono accesso al DOM.
6. Limitare il numero di nodi DOM nella pagina a meno di 1.500 elementi.

CLS: Cumulative Layout Shift

Il Cumulative Layout Shift misura la stabilità visiva della pagina. Quantifica quanto il contenuto si sposta in modo imprevisto durante il caricamento e l'interazione. Ogni spostamento che avviene senza che l'utente lo abbia causato (cliccando un pulsante, ad esempio) contribuisce al punteggio CLS.

Il valore viene calcolato moltiplicando la fraction of impact (la porzione di viewport occupata dagli elementi che si spostano) per la distance fraction (la distanza dello spostamento in rapporto al viewport). Più elementi si spostano e più si spostano in grande, più alto sarà il punteggio.

Soglie CLS

• Buono: entro 0,1
• Da migliorare: tra 0,1 e 0,25
• Scarso: oltre 0,25

Come per le altre metriche, il valore considerato e il 75esimo percentile. CLS è una metrica cumulativa: somma tutti gli spostamenti non causati dall'utente durante la visita. Google utilizza una finestra di sessione con un gap massimo di un secondo è una durata massima di cinque secondi per raggruppare gli spostamenti correlati.

Cause comuni di CLS elevato

La causa numero uno sono le immagini e i video senza dimensioni esplicite. Quando il browser non conosce le dimensioni di un'immagine prima di caricarla, riserva zero spazio nel layout. Quando l'immagine arriva, il contenuto circostante si sposta per farle posto. Specificare sempre width e height nell'HTML o usare la proprieta CSS aspect-ratio risolve questo problema.

I font web rappresentano un'altra fonte frequente di layout shift. Quando un font personalizzato viene caricato in ritardo, il browser mostra prima un font di fallback con metriche diverse. Il passaggio dal fallback al font definitivo causa uno spostamento del testo. L'utilizzo di font-display: swap combinato con size-adjust per uniformare le metriche dei font riduce significativamente questo problema.

I banner pubblicitari e i contenuti dinamici iniettati sopra il contenuto visibile sono un'altra causa comune. Un banner che si carica nella parte alta della pagina dopo il rendering iniziale spinge verso il basso tutto il contenuto sottostante. La soluzione e riservare uno spazio fisso per questi elementi nel layout tramite min-height o un container con dimensioni predefinite.

I cookie banner e i widget di chat che appaiono senza uno spazio riservato causano spesso shift significativi. Posizionarli con position: fixed o position: sticky, in modo che si sovrappongano al contenuto senza spostarlo, elimina il loro impatto sul CLS.

Ottimizzazione CLS: interventi chiave

1. Specificare sempre width e height per immagini e video nell'HTML.
2. Usare la proprieta CSS aspect-ratio per i container di media responsive.
3. Applicare font-display: optional o font-display: swap con size-adjust.
4. Riservare spazio fisso per banner pubblicitari e contenuti caricati dinamicamente.
5. Posizionare cookie banner e widget di chat con position: fixed.
6. Evitare di inserire contenuto sopra elementi già visibili nel viewport.

Come misurare i Core Web Vitals

La misurazione dei Core Web Vitals avviene attraverso due tipi di dati: dati di campo (field data) raccolti da utenti reali e dati di laboratorio (lab data) generati in ambienti controllati. Entrambi sono utili, ma servono a scopi diversi. Google utilizza i dati di campo per il ranking, mentre i dati di laboratorio servono per diagnosticare e risolvere i problemi.

Strumenti principali

Ecco gli strumenti più utilizzati per misurare e monitorare i Core Web Vitals, con le rispettive caratteristiche.

PageSpeed Insights — fornisce sia dati di campo (dal Chrome UX Report) che dati di laboratorio (da Lighthouse). È lo strumento più completo per una prima analisi. I dati di campo riflettono le esperienze reali degli utenti negli ultimi 28 giorni. I dati di laboratorio aiutano a identificare le cause specifiche dei problemi.

Google Search Console — il rapporto Segnali web essenziali mostra quali pagine del sito hanno problemi di Core Web Vitals, raggruppandole per tipo di problema. È lo strumento migliore per avere una visione d'insieme sull'intero sito e monitorare i progressi nel tempo.

Chrome UX Report (CrUX) — il dataset pubblico da cui PageSpeed Insights e Search Console attingono i dati di campo. Accessibile tramite BigQuery o l'API CrUX, offre dati storici e segmentazione per dispositivo, paese e tipo di connessione. Utile per analisi avanzate e confronti con i competitor.

Lighthouse — integrato in Chrome DevTools, genera report dettagliati con suggerimenti specifici per ogni metrica. Produce solo dati di laboratorio, simulando una connessione e un dispositivo predefiniti. Ideale per il debug in fase di sviluppo.

Web Vitals Extension — estensione per Chrome che mostra in tempo reale i valori di LCP, INP e CLS mentre navighi. Utile per verificare rapidamente l'impatto delle modifiche e identificare le interazioni più lente.

Quale strumento usare

Per una prima diagnosi, PageSpeed Insights è il punto di partenza ideale. Per monitorare l'andamento nel tempo e individuare le pagine problematiche su tutto il sito, Google Search Console e insostituibile. Per il debug tecnico durante lo sviluppo, Lighthouse e Chrome DevTools offrono il livello di dettaglio necessario. La combinazione di tutti e tre gli strumenti copre ogni esigenza.

Un aspetto importante da tenere presente: i dati di laboratorio e quelli di campo possono divergere in modo significativo. Lighthouse simula un dispositivo Moto G Power con connessione 4G lenta, che rappresenta una situazione peggiore di quella sperimentata da molti utenti reali. Al contrario, i dati di campo potrebbero rivelare problemi non emersi in laboratorio, perché gli utenti reali utilizzano dispositivi e connessioni diverse.

Ottimizzazione pratica: checklist per priorità

Migliorare i Core Web Vitals richiede un approccio strutturato. Non tutti gli interventi hanno lo stesso impatto, quindi è importante concentrarsi prima su quelli che producono i benefici più significativi. La seguente checklist e ordinata per priorità, dalla più alta alla più bassa.

1. Ottimizzare le immagini: convertire in WebP o AVIF, specificare dimensioni, aggiungere fetchpriority="high" all'immagine LCP e lazy loading alle immagini below the fold.
2. Ridurre il TTFB: attivare una CDN, configurare la cache del server, ottimizzare le query del database e ridurre le catene di redirect.
3. Eliminare il render-blocking: inlinare il CSS critico, caricare il CSS non critico in modo asincrono, aggiungere defer o async agli script non essenziali.
4. Riservare spazio nel layout: specificare width e height per tutti i media, usare aspect-ratio per i container responsive, fissare le dimensioni dei banner e dei widget.
5. Ottimizzare i font: usare font-display: swap con size-adjust, fare preload dei font critici, limitare il numero di varianti caricate.
6. Ridurre il JavaScript: eliminare il codice inutilizzato con tree shaking, spezzare i bundle con code splitting, ritardare il caricamento degli script di terze parti.
7. Spezzare i long task: usare requestIdleCallback o scheduler.yield, spostare i calcoli pesanti nei web worker, ridurre la complessità dei gestori di eventi.
8. Monitorare nel tempo: configurare il rapporto Segnali web essenziali in Search Console, impostare alert per regressioni e verificare i punteggi dopo ogni deploy.

Per identificare con precisione le aree critiche del tuo sito e definire un piano di intervento, il primo passo e partire da un audit tecnico del sito. Un'analisi approfondita rivela i colli di bottiglia specifici e consente di assegnare le priorità in base all'impatto reale sulle metriche.

Quanto impattano i Core Web Vitals sul ranking

Google ha sempre dichiarato che i Core Web Vitals sono un fattore di ranking, ma non il più importante. Il contenuto rilevante, i backlink autorevoli e la corrispondenza con l'intento di ricerca restano i segnali predominanti. I Core Web Vitals agiscono come un fattore di dipartita: a parita di rilevanza e autorità, il sito con metriche migliori ha un vantaggio.

Studi indipendenti condotti tra il 2024 e il 2026 confermano questa posizione. Un'analisi pubblicata da Searchmetrics su 500.000 URL ha mostrato che i siti con tutti e tre i Core Web Vitals nella fascia "buono" si posizionano in media 3,2 posizioni più in alto rispetto a siti con metriche "scarse", a parita di altri fattori. L'effetto e più pronunciato nelle ricerche da mobile, dove l'esperienza utente ha un peso maggiore.

Il vero impatto dei Core Web Vitals va però oltre il ranking diretto. Un sito veloce e stabile migliora i segnali comportamentali degli utenti: riduce il tasso di rimbalzo, aumenta il tempo di permanenza e incrementa le conversioni. Questi segnali indiretti influenzano positivamente il posizionamento nel lungo periodo.

I dati del settore e-commerce sono particolarmente eloquenti. Secondo i case study pubblicati da Google nel 2025, un miglioramento di LCP di un secondo ha generato un aumento medio delle conversioni del 27 percento su un campione di siti retail. Per un'attività con fatturato online significativo, questo si traduce in un ritorno sull'investimento immediato e misurabile.

Il consiglio pratico è questo: non ossessionarsi con i Core Web Vitals a scapito del contenuto, ma non ignorarli. Se il tuo sito ha metriche nella fascia "scarso", stai perdendo sia utenti che posizioni. Se sei nella fascia "buono", concentra le risorse su contenuti e autorità.

Un errore comune e dedicare settimane all'ottimizzazione per passare da un LCP di 2,0 secondi a 1,8 secondi. Quel miglioramento, pur positivo, ha un impatto marginale sul ranking. Lo stesso tempo investito nella creazione di contenuti di qualità o nella costruzione di backlink produrrebbe risultati molto superiori.

Se il tuo sito presenta problemi di Core Web Vitals che non riesci a risolvere, un' analisi professionale delle performance può identificare le cause e definire un piano di intervento mirato, integrandolo nella strategia SEO complessiva.

Errori frequenti nell'ottimizzazione dei Core Web Vitals

L'ottimizzazione dei Core Web Vitals non è sempre intuitiva. Alcuni interventi che sembrano migliorare le metriche possono in realtà peggiorarle o creare nuovi problemi. Ecco gli errori più comuni da evitare.

• Lazy loading dell'immagine LCP: applicare il lazy loading all'immagine principale above the fold ritarda il suo caricamento, peggiorando LCP. L'immagine LCP deve essere caricata con priorità alta e mai con loading="lazy".
• Nascondere il contenuto per ridurre CLS: rendere invisibile il contenuto fino al caricamento completo della pagina azzera il CLS ma distrugge LCP, perché il browser non può misurare il rendering di elementi invisibili. Il contenuto principale deve essere sempre visibile.
• Caricare tutto in modo asincrono: aggiungere async a tutti gli script senza criterio può causare problemi di dipendenze e peggiorare INP. Gli script devono essere caricati con la strategia appropriata: defer per quelli che dipendono dal DOM, async per quelli indipendenti.
• Ottimizzare solo i dati di laboratorio: concentrarsi sul punteggio di Lighthouse ignorando i dati di campo può portare a ottimizzazioni che non riflettono l'esperienza reale degli utenti. I dati del Chrome UX Report sono quelli che Google usa per il ranking.
• Ignorare le pagine interne: molti ottimizzano solo la homepage e le landing page principali. Google valuta i Core Web Vitals a livello di singola pagina. Se le pagine di categoria, le schede prodotto o gli articoli del blog hanno metriche scarse, il loro posizionamento ne risente.

L'approccio corretto e misurare prima, intervenire poi. Ogni modifica dovrebbe essere verificata sia con dati di laboratorio (per confermare l'effetto tecnico) sia con dati di campo (per validare l'impatto sugli utenti reali). I dati di campo richiedono circa 28 giorni per aggiornarsi nel Chrome UX Report, quindi la pazienza è essenziale.

Core Web Vitals nel 2026: cosa aspettarsi

Google aggiorna periodicamente le metriche dei Core Web Vitals per riflettere meglio l'esperienza utente. Il passaggio da FID a INP nel marzo 2024 ha dimostrato che le metriche non sono fisse, ma evolvono in base alla capacità di Google di misurare nuovi aspetti dell'interazione.

Al momento non ci sono annunci ufficiali su modifiche alle soglie o l'introduzione di nuove metriche per il 2026. Tuttavia, la tendenza di Google è chiara: le metriche diventeranno sempre più sofisticate nella misurazione dell'esperienza reale. E ragionevole aspettarsi che in futuro vengano introdotte metriche relative alla fluidita delle animazioni o alla percezione di velocità oltre il caricamento iniziale.

Per chi gestisce un sito web, la strategia migliore non è rincorrere le singole metriche, ma costruire una base tecnica solida. Un sito con codice pulito, immagini ottimizzate, JavaScript efficiente e un hosting performante superera qualsiasi aggiornamento futuro delle metriche senza interventi drastici.

I Core Web Vitals sono un aspetto di una strategia SEO più ampia. Non sostituiscono la necessità di contenuti pertinenti, di un profilo backlink autorevole e di una struttura del sito coerente. Ma offrono un vantaggio competitivo reale, soprattutto in settori dove molti concorrenti ancora li trascurano. Investire nell'ottimizzazione delle performance significa investire nella soddisfazione degli utenti, è questo e un obiettivo che va sempre nella direzione giusta.