In un test A/B di Vodafone Italia con due pagine visivamente e funzionalmente identiche, migliorare l'LCP del 31% è stato sufficiente a generare l'8% in più di vendite, secondo il caso di studio ufficiale di web.dev. Non si tratta di un dettaglio tecnico riservato al team di sviluppo: è una variabile diretta del fatturato. I Core Web Vitals misurano con precisione quell'esperienza che decide, nei primi secondi, se un visitatore acquista, contatta o va dalla concorrenza.
Se gestite il sito di un'azienda B2B, questo vi riguarda tanto quanto un e-commerce. Un modulo di contatto lento a rispondere, un hero che salta durante il caricamento o una pagina lenta su mobile sono perdite silenziose di conversione. In questa guida vedrete cosa sono esattamente i Core Web Vitals, quali soglie richiede Google nel 2026, come misurarli con dati affidabili e come ottimizzare ogni metrica passo dopo passo.
Cosa sono i Core Web Vitals e perché sono importanti per la SEO nel 2026
I Core Web Vitals sono un sottoinsieme delle metriche di page experience che Google considera essenziali per valutare l'esperienza reale dell'utente su qualsiasi sito web. Non misurano se una pagina "è bella", ma tre dimensioni misurabili del suo comportamento: quanto impiega a mostrare il contenuto principale, come risponde alle interazioni dell'utente e quanto si muove il layout durante il caricamento.
Nel 2026 sono tre le metriche:
- LCP (Largest Contentful Paint) — velocità di caricamento dell'elemento più grande visibile.
- INP (Interaction to Next Paint) — reattività alle interazioni.
- CLS (Cumulative Layout Shift) — stabilità visiva del layout.
Sono importanti per la SEO perché fanno parte dei segnali di page experience che Google valuta. Ma sono ancora più importanti per il business. Google ha documentato risultati come quelli di iCook, che ha aumentato del 10% i ricavi pubblicitari migliorando il CLS del 15%; Tokopedia, con un 23% in più di durata media della sessione dopo aver ridotto l'LCP del 55%; o Nykaa, che ha ottenuto il 28% in più di traffico organico migliorando l'LCP del 40%. Sono cifre dal repository ufficiale di casi di studio di web.dev, non stime di agenzia.
La conclusione pratica: ottimizzare i Core Web Vitals non è un "lavoro da idraulici" che piace solo a Google. È una leva di conversione, fidelizzazione e, in ultima analisi, di pipeline commerciale.
LCP, INP e CLS: soglie raccomandate da Google
Google non usa una scala continua: classifica ogni metrica in tre categorie —"buona", "da migliorare" e "scarsa"— a partire da soglie fisse. Per superare la valutazione, l'obiettivo è sempre la categoria "buona". Questi sono i valori ufficiali secondo la documentazione di web.dev sulla definizione delle soglie dei Core Web Vitals:
| Metrica | Cosa misura | Buona | Da migliorare | Scarsa |
|---|---|---|---|---|
| LCP | Velocità di caricamento del contenuto principale | <= 2,5 s | 2,5 s – 4,0 s | > 4,0 s |
| INP | Reattività alle interazioni | <= 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS | Stabilità visiva (spostamento del layout) | <= 0,1 | 0,1 – 0,25 | > 0,25 |
C'è una sfumatura che cambia completamente il modo di interpretare i propri report: Google valuta queste soglie al 75° percentile delle visite reali. Ciò significa che affinché un URL superi una metrica, almeno il 75% delle visualizzazioni di pagina deve raggiungere la soglia "buona". Questo significa che non basta che la pagina sia veloce sul vostro laptop di fascia alta con fibra ottica: deve esserlo anche per il quarto utente più lento su quattro, di solito qualcuno con uno smartphone di fascia media e una connessione mobile discontinua.
Per questo motivo una pagina può "sembrare veloce" quando la testate voi e tuttavia non superare i Core Web Vitals su CrUX. Il 75° percentile obbliga a progettare pensando allo scenario peggiore ragionevole, non al migliore.
Perché INP ha sostituito FID a marzo 2024
Per anni, la metrica di reattività è stata FID (First Input Delay), che misurava solo il ritardo della prima interazione dell'utente e, per di più, unicamente il ritardo fino a quando il browser iniziava a elaborarla. Era una metrica generosa: la maggior parte dei siti la superava con facilità, il che la rendeva poco utile per distinguere le esperienze davvero fluide da quelle che non lo erano.
INP (Interaction to Next Paint) ha sostituito ufficialmente FID come Core Web Vital di reattività il 12 marzo 2024, dopo essere stato annunciato il 31 gennaio dello stesso anno, secondo il blog di web.dev. La differenza è sostanziale:
- FID misurava solo la prima interazione; INP osserva tutte le interazioni della sessione e riporta (approssimativamente) la peggiore.
- FID misurava solo il ritardo di input; INP misura l'intero ciclo, fino a quando il fotogramma successivo (next paint) riflette visivamente la risposta.
In pratica, INP è molto più esigente e molto più rappresentativo di come l'utente percepisce l'agilità del sito. Una pagina che apriva i menu lentamente, validava i moduli con ritardo o reagiva tardi ai clic —cose invisibili per FID— è ora esposta. Per i siti B2B con moduli lunghi, filtri di prodotto o configuratori, questo cambiamento è stato particolarmente rilevante.
Come misurare i Core Web Vitals: PageSpeed Insights, CrUX e Search Console
Ecco l'errore più comune e più costoso: confondere i dati di laboratorio con i dati di campo. Non sono la stessa cosa e solo uno di essi conta per il ranking.
Dati di campo vs. dati di laboratorio
- Dati di campo (field data): misurazioni degli utenti reali che visitano il vostro sito, raccolte tramite il Chrome User Experience Report (CrUX). È una media mobile su 28 giorni.
- Dati di laboratorio (lab data): una simulazione controllata in un ambiente fisso, generata da Lighthouse.
Secondo la documentazione di web.dev sul perché i dati di laboratorio e di campo differiscono, Google usa per il ranking esclusivamente i dati di campo di CrUX, non quelli di laboratorio di Lighthouse. Questi ultimi servono per la diagnosi: indicano perché qualcosa non va, ma non sono il voto che conta. Per questo è perfettamente possibile ottenere 100 in Lighthouse e tuttavia non superare i Core Web Vitals su CrUX se gli utenti reali hanno un'esperienza peggiore rispetto all'ambiente simulato.
Quale strumento usare e per cosa
| Strumento | Tipo di dato | Granularità | Uso ottimale |
|---|---|---|---|
| PageSpeed Insights | Campo (CrUX) + laboratorio (Lighthouse) | URL singolo; CrUX aggiornato quotidianamente | Diagnosi di una pagina specifica |
| Google Search Console | Solo campo (CrUX) | Aggregato per gruppi di URL | Visione dello stato del sito e URL problematici |
| Lighthouse / DevTools | Solo laboratorio | URL singolo, esecuzione puntuale | Debug e test dei miglioramenti prima del deploy |
Secondo la documentazione di Google for Developers su PageSpeed Insights, lo strumento mostra sia dati di campo di CrUX (aggiornati quotidianamente a livello di URL) sia dati di laboratorio di Lighthouse. Google Search Console, invece, riporta esclusivamente dati di campo di CrUX aggregati per gruppi di URL, il che la rende il pannello ideale per rilevare su larga scala quali template o sezioni del sito presentano problemi.
Il flusso di lavoro consigliato:
- Search Console per identificare quali gruppi di URL non superano la valutazione.
- PageSpeed Insights per diagnosticare perché un URL rappresentativo non funziona correttamente.
- Lighthouse / DevTools per iterare le correzioni in locale.
- Effettuare il deploy e attendere che la media mobile di 28 giorni di CrUX registri il miglioramento.
Quest'ultimo punto è fondamentale: poiché CrUX è una media su 28 giorni, una correzione non si riflette immediatamente. È necessaria pazienza e non bisogna revertire modifiche positive per impazienza.
Come ottimizzare ogni metrica passo dopo passo
Ogni Core Web Vital ha cause diverse e, quindi, soluzioni diverse. Questa è una checklist prioritizzata per impatto tipico.
Ottimizzare l'LCP (<= 2,5 s)
L'LCP è solitamente limitato dal tempo necessario per caricare e renderizzare l'elemento principale (normalmente un'immagine hero, un blocco di testo grande o un video).
- Servire l'immagine LCP con priorità (
fetchpriority="high") ed evitare il lazy-loading su quell'elemento specifico. - Ottimizzare il formato dell'immagine (AVIF o WebP) e dimensionare correttamente per ogni breakpoint.
- Precaricare le risorse critiche (font, immagine hero) ed eliminare le risorse che bloccano il rendering.
- Ridurre il tempo di risposta del server (TTFB) con cache, CDN e rendering efficiente.
- Minimizzare il CSS e il JavaScript critici che ritardano la prima pittura.
Ottimizzare l'INP (<= 200 ms)
L'INP quasi sempre si deteriora a causa di JavaScript che blocca il thread principale quando l'utente interagisce.
- Suddividere i task lunghi (long tasks) in frammenti più piccoli per non bloccare il thread.
- Posticipare o eliminare JavaScript di terze parti non essenziale (chat, widget, tag di marketing pesanti).
- Usare
content-visibilitye rendering differito per i contenuti fuori schermo. - Evitare re-render non necessari in framework come React ottimizzando lo stato e la memoizzazione.
- Fornire feedback visivo immediato all'interazione anche se l'elaborazione continua in background.
Ottimizzare il CLS (<= 0,1)
Il CLS è il meno costoso da correggere e quello che dà più fastidio all'utente: elementi che saltano proprio quando sta per cliccare.
- Riservare spazio per immagini e video con attributi
widtheheightoaspect-ratio. - Riservare spazio per annunci e embed prima che vengano caricati.
- Precaricare i font e usare
font-display: optionaloswapper evitare reflow del testo. - Non inserire mai contenuto sopra quello esistente salvo in risposta diretta a un'azione dell'utente.
- Animare con
transform, non con proprietà che causino il ricalcolo del layout.
Questo tipo di lavoro —misurazione con dati di campo, budget di prestazione e correzioni prioritizzate— è esattamente ciò che affrontiamo in un progetto di SEO tecnico ben governato, dove le prestazioni smettono di essere un'incidenza occasionale per diventare uno standard di qualità continuo. E quando il problema è alla base del codice, lo risolviamo a livello di sviluppo web, intervenendo sull'architettura del front-end, il rendering e la distribuzione delle risorse.
I Core Web Vitals influenzano davvero il posizionamento?
È la domanda da un milione di euro, e la risposta onesta ha due parti.
Sì, sono un segnale di ranking, ma non il più importante. Secondo la documentazione di Google Search Central sui Core Web Vitals, Google conferma che la page experience —inclusi i Core Web Vitals— è uno dei molti segnali che il suo sistema valuta. Nella stessa fonte, Google ricorda esplicitamente che un contenuto di qualità rimane prioritario rispetto alla page experience.
Come tradurre questo in una strategia realistica:
I Core Web Vitals non porteranno un contenuto mediocre sopra un contenuto eccellente. Ma quando due pagine competono con contenuti di qualità comparabile, la page experience può essere il fattore che fa pendere la bilancia —e, soprattutto, quello che determina se il visitatore che arriva rimane e converte.
Per questo l'approccio corretto non è inseguire un 100 in Lighthouse come fine a sé stesso, ma:
- Assicurare prima un contenuto di valore che risponda all'intento di ricerca.
- Superare i Core Web Vitals al 75° percentile degli utenti reali come standard di qualità non negoziabile.
- Trattare le prestazioni come variabile di business, non solo di SEO, per il loro impatto dimostrato su conversione e fidelizzazione.
Il rischio maggiore non è restare a pochi decimi dalla soglia: è ignorare completamente i dati di campo e scoprire, mese dopo mese, perché gli utenti abbandonano senza che i dati di laboratorio spieghino nulla.
Volete sapere dove il vostro sito perde prestazioni e quanto vi sta costando in termini di conversione? In Technova Partners analizziamo i vostri Core Web Vitals con dati di campo reali, prioritizziamo le correzioni per impatto e le implementiamo fino a superare il 75° percentile. Parlate con il nostro team e trasformate le prestazioni web in un vantaggio misurabile rispetto alla concorrenza.
