Core Web Vitals: cosa sono e come migliorarli nel 2026

Hai un sito veloce sulla tua macchina, ma quando lo apri da smartphone in metropolitana sembra un altro prodotto. Gli utenti chiudono prima ancora che il pulsante "Acquista" appaia, e tu te ne accorgi solo guardando il bounce rate. Qui entrano in gioco i Core Web Vitals: tre metriche definite da Google che misurano quanto la tua pagina è davvero usabile per chi la visita. Non sono un capriccio tecnico: incidono sul posizionamento organico e, soprattutto, sul tasso di conversione.

In questa guida vediamo cosa sono i Core Web Vitals, quali sono le soglie da rispettare nel 2026, come migliorarli senza rifare il sito da zero e quali errori commettono spesso anche le agenzie più strutturate.

Cosa sono i Core Web Vitals

I Core Web Vitals sono un sottoinsieme dei Web Vitals: un set di metriche definite da Google per misurare la qualità dell'esperienza utente su una pagina web. Misurano tre dimensioni concrete: quanto velocemente compare il contenuto principale, quanto è reattivo il sito alle interazioni e quanto è stabile visivamente.

A differenza di indicatori più astratti come il "page load time", i Core Web Vitals sono pensati per fotografare ciò che l'utente percepisce davvero. Google li usa come segnale di ranking dal 2021 e li aggiorna periodicamente: nel marzo 2024, INP (Interaction to Next Paint) ha sostituito il vecchio FID, rendendo la misurazione più severa.

Le tre metriche che contano

• LCP — Largest Contentful Paint: tempo necessario perché il contenuto principale della pagina (di solito l'immagine hero o il blocco di testo più grande) diventi visibile. Misura la velocità percepita di caricamento.
• INP — Interaction to Next Paint: tempo che intercorre tra un'interazione dell'utente (click, tap, tasto) e la risposta visiva del sito. Misura la reattività complessiva.
• CLS — Cumulative Layout Shift: quanto la pagina "salta" durante il caricamento, spostando bottoni e testi sotto il dito dell'utente. Misura la stabilità visiva.

Le soglie dei Core Web Vitals da rispettare

Google considera una pagina "buona" solo se tutte e tre le metriche restano sotto specifici limiti per il 75° percentile degli utenti reali. Significa che il 75% delle visite deve avere un'esperienza accettabile, non solo la media.

Le soglie ufficiali aggiornate al 2026 sono:

• LCP: buono ≤ 2,5 s — da migliorare 2,5–4 s — scadente > 4 s
• INP: buono ≤ 200 ms — da migliorare 200–500 ms — scadente > 500 ms
• CLS: buono ≤ 0,1 — da migliorare 0,1–0,25 — scadente > 0,25

Una pagina che fallisce anche solo una di queste tre soglie risulta "non superata" agli occhi di Google. È un dettaglio importante: non basta avere un LCP ottimo se l'INP è sopra i 500 ms.

Perché i Core Web Vitals sono importanti per il tuo business

Spesso si parla dei Core Web Vitals come di un tema "SEO". È vero solo a metà. Il vero impatto è sul comportamento degli utenti. Ogni secondo in più di caricamento riduce le conversioni in modo misurabile: Google stesso ha pubblicato studi in cui un LCP che passa da 1 a 3 secondi aumenta la probabilità di abbandono del 32%.

Per un e-commerce, una piattaforma SaaS o una landing page commerciale questo significa fatturato perso. Per un sito vetrina significa lead che non arrivano. Per una web app B2B significa utenti che si lamentano e churn più alto.

L'impatto sul posizionamento Google

I Core Web Vitals fanno parte dei segnali di "Page Experience" che Google considera nel ranking. Non sono il fattore più pesante (la pertinenza del contenuto conta di più), ma a parità di rilevanza tra due risultati, Google premia quello con esperienza utente migliore. In nicchie competitive, questa differenza può valere posizioni.

Come misurare i Core Web Vitals

Prima di ottimizzare, devi misurare. Esistono due tipi di dati che fanno cose diverse, e confonderli è uno degli errori più frequenti.

Dati di laboratorio (lab data)

Sono simulazioni eseguite in ambiente controllato. Strumenti come Lighthouse (integrato in Chrome DevTools) o PageSpeed Insights in modalità "Origin" producono questo tipo di dati. Sono utili per il debug, perché ti dicono dove intervenire, ma non rispecchiano l'esperienza reale degli utenti.

Dati di campo (field data)

Sono raccolti dal Chrome User Experience Report (CrUX): misurazioni anonime dei Chrome reali degli utenti. Sono questi i dati che Google usa per il ranking. Li trovi in PageSpeed Insights (sezione "Discover what your real users are experiencing"), in Google Search Console (rapporto "Esperienza"), o tramite tool come Web Vitals Extension.

Regola pratica: usa i lab data per capire cosa aggiustare, i field data per sapere se l'aggiustamento ha funzionato davvero.

Come migliorare LCP: velocità di caricamento

L'LCP è la metrica più legata a quanto il tuo sito appare "veloce". Per migliorarlo, agisci su tre fronti.

Ottimizza il contenuto principale

Spesso l'elemento LCP è un'immagine grande (hero banner, prodotto, foto copertina). Comprimila in formato moderno (WebP o AVIF), servila in dimensioni adeguate al dispositivo e precarica quella sopra la piega con il tag <link rel="preload">. Se l'LCP è testo, assicurati che il font non blocchi il rendering: usa font-display: swap e precarica il font principale.

Riduci il tempo del server

Il TTFB (Time To First Byte) è il primo collo di bottiglia. Se il tuo server impiega 1,5 secondi a rispondere, hai già perso. Soluzioni: cache lato server, CDN per i contenuti statici, hosting con risorse adeguate al traffico, query database ottimizzate per le pagine più visitate.

Elimina le risorse bloccanti

CSS e JavaScript caricati nell'<head> bloccano il rendering. Minifica i file, rimuovi il CSS non utilizzato, sposta gli script non critici con defer o async, inline il CSS critico per la prima visualizzazione.

Se stai valutando un intervento serio sulle performance del tuo sito, possiamo aiutarti: contattaci dalla sidebar per una consulenza gratuita su Core Web Vitals e ottimizzazione.

Come migliorare INP: reattività alle interazioni

L'INP è la metrica più ostica perché dipende dal JavaScript che gira nel browser. Un sito che sembra veloce in caricamento può avere un INP terribile se ogni click scatena 300 ms di calcoli.

Spezzetta i task lunghi

Un "long task" è qualsiasi operazione JavaScript che blocca il thread principale per più di 50 ms. Identificali con il Performance panel di Chrome DevTools e spezzettali con tecniche come scheduler.yield(), requestIdleCallback, o semplicemente setTimeout(fn, 0) per cedere il controllo al browser.

Riduci il JavaScript di terze parti

Tag manager, pixel di tracking, chatbot, widget di recensioni: ognuno aggiunge millisecondi di esecuzione. Audita cosa carichi davvero e quando: spesso il 30% del peso JavaScript serve a funzioni che usano due utenti su mille.

Ottimizza i listener degli eventi

Evita event listener pesanti su eventi che si scatenano spesso (scroll, mousemove, input). Usa debouncing e throttling, delega gli eventi al document quando possibile, e sposta i calcoli costosi fuori dall'handler immediato.

Come migliorare CLS: stabilità visiva

Il CLS è il più semplice da capire: misura quanto la pagina "balla" durante il caricamento. È anche quello che frustra di più gli utenti, perché li porta a cliccare sull'elemento sbagliato.

Riserva spazio per immagini e iframe

Specifica sempre attributi width e height (o usa aspect-ratio in CSS). Il browser può così riservare lo spazio corretto prima che la risorsa carichi, ed evitare che il resto della pagina salti.

Gestisci bene i font web

I font remoti possono causare il temuto FOIT (Flash of Invisible Text) o FOUT (Flash of Unstyled Text). Usa font-display: optional o swap con fallback dimensionati il più possibile come il font finale.

Evita iniezioni dinamiche sopra il contenuto

Banner cookie, notifiche push, pubblicità inserite dopo il caricamento iniziale sono i killer del CLS. Riserva loro uno spazio fisso fin dall'inizio, oppure mostrali in posizioni che non spostino il contenuto già visibile.

Errori comuni da evitare

Anche team tecnici esperti cadono in trappole prevedibili quando si tratta di Core Web Vitals. Eccone alcune che incontriamo regolarmente nei nostri audit.

• Ottimizzare solo la homepage: Google misura per URL, non per dominio. Una homepage perfetta non basta se le pagine prodotto sono lente.
• Fidarsi solo del punteggio Lighthouse: è una simulazione. Il dato che conta per il ranking è quello degli utenti reali (CrUX).
• Caricare framework pesanti per siti semplici: usare React o Next.js per un sito vetrina di 5 pagine può degradare l'INP senza necessità.
• Ignorare il dispositivo mobile: il 75° percentile spesso si gioca su connessioni 4G lente e smartphone di fascia media. Testa lì, non sul tuo MacBook con la fibra.
• Trattare le performance come progetto one-shot: dopo un'ottimizzazione, ogni nuova feature può peggiorare le metriche. Servono monitoraggio continuo e budget di performance.

Checklist pratica per i tuoi Core Web Vitals

Se vuoi un punto di partenza concreto, ecco una sequenza operativa che funziona nella maggior parte dei casi:

1. Apri Google Search Console e controlla il rapporto "Esperienza sulla pagina" per vedere quali URL sono "scadenti" o "da migliorare".
2. Per ogni URL critico, lancia PageSpeed Insights e guarda sia il pannello "Field Data" sia "Lab Data".
3. Identifica la metrica peggiore e parti da quella: spesso un singolo intervento (es. comprimere l'hero image) migliora più metriche insieme.
4. Implementa una correzione alla volta, in produzione, e aspetta 28 giorni per vedere come si muovono i dati di campo (CrUX ha una finestra mobile di 28 giorni).
5. Imposta un alert (con tool come SpeedCurve, Calibre o Sentry) per essere avvisato quando una metrica peggiora dopo un deploy.
6. Inserisci un controllo Lighthouse nel CI/CD: ogni pull request deve rispettare soglie minime prima di andare in produzione.

Quando rivolgersi a uno specialista

Per siti semplici basati su CMS standard, una buona dose di ottimizzazione delle immagini e un hosting decente bastano. Quando invece hai una web app complessa, un e-commerce con molti script di terze parti o una piattaforma SaaS con tempi di risposta critici, intervenire da soli rischia di peggiorare le cose.

In questi casi serve un audit completo che includa profiling JavaScript, analisi del backend, rivisitazione dell'architettura frontend (es. passaggio a SSR, ISR o islands architecture) e definizione di un performance budget concordato con il team di sviluppo.

Conclusione

I Core Web Vitals non sono una moda passeggera né un capriccio di Google. Sono il modo più diretto con cui un motore di ricerca quantifica quello che gli utenti sentono usando il tuo sito: quanto è veloce, quanto è reattivo, quanto è stabile. Migliorarli significa migliorare insieme posizionamento, conversioni e percezione del brand.

Non serve riscrivere tutto da zero. Serve misurare con onestà, intervenire dove il dato lo richiede e costruire una cultura del performance budget che protegga i risultati nel tempo.

Hai bisogno di supporto per analizzare e migliorare i Core Web Vitals del tuo sito o della tua web app? Scrivici: trovi il form di contatto qui a destra. Facciamo un audit insieme e ti diciamo dove vale la pena intervenire davvero.