Core Web Vitals: come migliorare prestazioni e SEO del sito
LCP, CLS e INP misurano caricamento, stabilità e reattività. Come interpretarli, distinguere test e dati reali e scegliere gli interventi utili.
Un sito lento o difficile da usare può far perdere richieste. I Core Web Vitals aiutano a misurare tre aspetti dell’esperienza: quanto rapidamente appare il contenuto principale, quanto è stabile la pagina e quanto risponde alle interazioni.
Google usa questi segnali nei propri sistemi di ranking, ma un buon risultato non garantisce posizioni migliori. Contenuti pertinenti, utilità e altri segnali restano determinanti, come spiega la documentazione Google sull’esperienza sulle pagine.
Quali sono le metriche Core Web Vitals?
Le metriche sono LCP, CLS e INP. Per superare la valutazione, tutte e tre devono essere nella fascia buona al 75° percentile delle visite reali, con mobile e desktop valutati separatamente. Un test Lighthouse simula una visita: aiuta a diagnosticare problemi, ma non sostituisce questa misura di campo.
LCP, Largest Contentful Paint
Misura il tempo che passa tra l’inizio della navigazione e il momento in cui l'elemento più grande della pagina (di solito l'immagine hero o un titolone) diventa visibile.
- Buono: fino a 2,5 secondi
- Da migliorare: oltre 2,5 e fino a 4 secondi
- Scarso: sopra 4 secondi
Un LCP elevato indica che il contenuto principale tarda ad apparire. L’impatto su abbandoni e richieste va misurato sul pubblico del sito, senza attribuire una percentuale universale.
CLS, Cumulative Layout Shift
Quando apri una pagina e i contenuti "saltano" perché un'immagine si carica in ritardo, quella è CLS. Misura quanto la pagina si sposta sotto gli occhi dell'utente mentre carica.
- Buono: fino a 0,1
- Scarso: sopra 0,25
Un CLS alto può rendere difficile leggere o premere il pulsante corretto. Non corrisponde a una penalizzazione automatica di Google.
INP, Interaction to Next Paint
Ha sostituito FID nel 2024. Misura la reattività del sito: quanto tempo passa da quando clicchi un bottone a quando succede qualcosa di visibile.
- Buono: fino a 200 ms
- Scarso: sopra 500ms
Le soglie Google e le soglie operative di Webica Labs
Google definisce tre fasce per ogni metrica: buono, da migliorare e scarso. I nostri target operativi servono a orientare il lavoro e creare margine; non certificano il ranking né garantiscono che ogni visita rispetti le soglie.
| Metrica Core Web Vitals | Fascia buona, 75° percentile | Target operativo Webica | Cosa misura |
|---|---|---|---|
| LCP | ≤ 2,5 s | ≤ 1,5 s | Tempo al contenuto principale visibile |
| CLS | ≤ 0,1 | ≤ 0,05 | Stabilità visiva |
| INP | ≤ 200 ms | ≤ 150 ms | Reattività alle interazioni |
TBT e TTFB non sono Core Web Vitals. Il TBT è una misura di laboratorio del blocco del thread principale; il TTFB misura il tempo al primo byte della risposta. Sono utili per individuare le cause di un problema. Per il TBT usiamo un target di laboratorio di 150 ms e per il TTFB un target operativo di 600 ms, specificando sempre le condizioni del test.
Le definizioni, le soglie e il metodo di valutazione sono nella guida ufficiale ai Web Vitals.
Come leggere PageSpeed Insights
- Apri PageSpeed Insights e inserisci l’URL.
- Controlla se sono disponibili dati reali e se riguardano la singola pagina oppure l’intero dominio.
- Leggi separatamente la sezione diagnostica Lighthouse: il punteggio da 0 a 100 non è un voto SEO e può variare tra esecuzioni.
- Confronta mobile e desktop. Se il traffico è soprattutto mobile, parti dai problemi che coinvolgono quel pubblico.
- Chiedi a chi segue il sito una lista di interventi collegati alle misure e una verifica successiva.
L’assenza di dati reali può dipendere dal campione disponibile: non significa che il sito sia veloce o lento. Anche l’INP richiede interazioni reali e non si ricava dal solo caricamento iniziale di Lighthouse.
Quali interventi migliorano le prestazioni?
La priorità dipende dal problema misurato:
- Immagini: dimensioni adatte allo schermo, formati efficienti, caricamento prioritario dell’immagine LCP e lazy loading per quelle lontane dalla prima schermata.
- Font: limitare varianti e pesi, scegliere fallback stabili e precaricare soltanto i file critici.
- JavaScript: ridurre il lavoro sul thread principale e rimandare le funzioni non necessarie all’avvio.
- Server: analizzare tempi di risposta, cache e carico prima di cambiare hosting.
Si misura, si individua la causa e si ripete il test nelle stesse condizioni. La guida web.dev all’ottimizzazione LCP distingue tempo del server, scoperta della risorsa, download e ritardo di rendering.
Caso reale: come RD Assicurazioni è passata dal rosso verso il verde
RD Assicurazioni è un'agenzia assicurativa monomandataria con sede a Roma. Il consulente Riccardo Angalli lavora principalmente con aziende, piccole imprese e partite IVA, in un settore dove la concorrenza digitale è forte: comparatori come Prima.it e Segugio.it dominano il traffico informazionale, e per un agente locale guadagnare visibilità organica significa avere un sito tecnicamente inattaccabile.
Quando abbiamo analizzato rdassicurazioni.com a inizio maggio 2026, il quadro CWV era questo: un sito già ben strutturato sul piano semantico (preload dei font critici, fetchpriority="high" sull'immagine hero, srcset responsive già implementato), ma con un'immagine LCP servita in formato JPG da 158 KB sul breakpoint largo. Su rete mobile simulata (throttling 4G slow, la condizione standard di Lighthouse), l'LCP arrivava a 7,8 secondi. Gli altri segnali erano già in ordine: CLS quasi zero, Thread principale libero.
L'intervento è stato chirurgico: conversione dell'immagine hero di Riccardo Angalli da JPG a AVIF (avifenc -q 60), generazione di 9 varianti responsive (3 soggetti × 3 breakpoint), aggiornamento del tag <picture> con <source type="image/avif"> come prima scelta su 4 pagine pillar, e aggiornamento del <link rel="preload"> da WebP ad AVIF. Nessun refactoring strutturale, nessuna dipendenza nuova, nessun tocco al backend.
Il risultato in Lighthouse lab (throttling 4G slow, mobile, misurato post-deploy):
| Metrica | Prima (maggio 2026) | Dopo (maggio 2026) | Riferimento della metrica |
|---|---|---|---|
| Performance score | 70/100 | 73/100 | n/a |
| LCP | 7,8 s | 5,0 s | ≤ 2,5 s |
| CLS | 0,006 | 0,007 | ≤ 0,1 |
| FCP | ~3,5 s | 2,4 s | ≤ 1,8 s |
| TBT | ~80 ms | 40 ms | ≤ 200 ms |
Due cose da leggere correttamente in questa tabella. Prima: CLS e TBT erano già nella fascia ottima prima dell'intervento, e lo sono rimasti, perché il sito era costruito bene. Seconda: LCP è migliorato di oltre il 35% ma è ancora nella fascia "scarso" secondo le soglie Google. Questo è onesto. Il punto di partenza aveva un problema strutturale, e un singolo sprint di ottimizzazione immagini sposta il numero in modo significativo senza risolverlo completamente.
Il passo successivo per rdassicurazioni.com è lavorare sul Critical Rendering Path: analisi CSS unused (il foglio main.css da 35 KB ha regole non utilizzate), eventuale inline del CSS above-fold, e verifica del rendering path su connessione reale piuttosto che simulata. Queste sono attività che rientrano in un ciclo di ottimizzazione continua, non in un singolo deploy.
La cosa importante, dal punto di vista dell'esperienza utente: il sito carica in modo stabile, senza salti visivi, con un thread principale libero che non blocca i click. Per valutare i dispositivi reali servono misure sul campo; questi risultati descrivono solo il test simulato di maggio 2026, non lo stato attuale del sito.
Quanto costa portare un sito ai Core Web Vitals verdi?
Dipende dal punto di partenza. Un sito nato bene, costruito con un framework moderno e su hosting adeguato, arriva spesso nei verdi senza intervento specifico. Per questi siti la performance è una proprietà emergente dell'architettura, non un obiettivo separato da inseguire.
La situazione cambia con i siti legacy: WordPress con venti plugin che si parlano addosso, temi comprati su Themeforest mai aggiornati, immagini caricate dall'amministratore a 4 MB perché "funziona comunque", hosting condiviso economico. In questi casi il lavoro di ottimizzazione è reale e richiede un audit tecnico prima di stimare quanto tempo serve.
Quando costruiamo o seguiamo un sito, l'ottimizzazione delle performance fa parte del lavoro fin dall'inizio, non è un extra da aggiungere dopo. Il monitoraggio nel tempo serve a evitare che i numeri si degradino: un plugin aggiornato male o un'immagine caricata senza compressione possono far scivolare un sito dal verde all'arancio in silenzio.
Se invece hai un sito esistente e vuoi capire dove sta il problema, il punto di partenza è un audit. Nel caso di RD Assicurazioni, cinque minuti su PageSpeed Insights e un'ora di lavoro tecnico hanno spostato LCP di 2,8 secondi. Non sempre è così lineare, ma spesso il collo di bottiglia principale è uno e uno solo, e identificarlo correttamente aiuta a concentrare gli interventi.
Per un confronto sui tuoi numeri attuali, prenota una call: guardiamo insieme PageSpeed Insights, identifichiamo il problema principale, e capisci se ha senso un intervento e di che portata.
Perché ne parliamo su Webica Labs
Perché lavoriamo ogni giorno con aziende italiane e vediamo due scenari:
- Siti nati benissimo che sono stati "ottimizzati" in modo sbagliato negli anni e ora zoppicano.
- Siti nati male che nessuno ha mai misurato, finché il giro annuale di SEO agency di turno non arriva a dire "bisogna rifarlo tutto". Quasi sempre la velocità rotta è solo uno dei sette errori tipici che vediamo sui siti delle aziende.
Il punto di partenza è la misura. Si corregge ciò che pesa di più e si controlla l’effetto. Progettare bene un sito web aziendale aiuta a prevenire i problemi; contenuti, integrazioni e condizioni di navigazione possono comunque cambiare i risultati nel tempo.
Se vuoi capire se il tuo sito ha un problema reale o è "abbastanza ok", prenota una call. Guardiamo insieme i tuoi numeri e decidi tu cosa fare.