I Core Web Vitals sono un insieme di metriche introdotte da Google nel 2020 e diventate fattore di ranking ufficiale nel 2021 con il Page Experience Update. Misurano tre dimensioni fondamentali dell'esperienza utente: quanto velocemente si carica il contenuto principale della pagina, quanto rapidamente risponde alle interazioni e quanto stabilmente si comporta il layout durante il caricamento. Se il tuo sito ha punteggi scadenti su queste metriche, Google lo penalizza nelle SERP rispetto a siti con contenuto simile ma performance migliori. In questa guida trovi tutto quello che devi sapere per capire, misurare e ottimizzare i Core Web Vitals — con valori target precisi, strumenti gratuiti e tecniche concrete applicabili anche senza uno sviluppatore.
Cosa sono i Core Web Vitals e perché Google li usa per il ranking
I Core Web Vitals fanno parte di un framework più ampio chiamato Page Experience Signals, che comprende anche HTTPS, assenza di interstitial invasivi e mobile-friendliness. Tuttavia, le tre metriche principali — LCP, INP e CLS — sono quelle che hanno il peso maggiore sul ranking. Google le raccoglie attraverso i dati reali degli utenti Chrome (il Chrome User Experience Report, abbreviato CrUX) e le confronta con i dati di laboratorio dei test PageSpeed. Questo significa che non basta avere un buon punteggio PageSpeed in laboratorio: quello che conta è l'esperienza dei tuoi visitatori reali, con le loro connessioni, i loro dispositivi e le loro condizioni d'uso. Un sito che carica in 1,2 secondi nel test di laboratorio ma serve immagini non ottimizzate su rete mobile può tranquillamente avere un LCP di 4-5 secondi nel campo reale. Per avere accesso ai dati CrUX del tuo sito, il tuo dominio deve ricevere abbastanza traffico da essere incluso nel dataset — se il sito è nuovo o ha pochissime visite, Google Search Console mostrerà il messaggio "dati insufficienti" e dovrai affidarti esclusivamente ai dati di laboratorio finché il traffico non cresce.
Il meccanismo con cui i Core Web Vitals influenzano il ranking non è semplice come un punteggio numerico. Google applica un sistema a soglie: ogni metrica ha tre zone — Buono (verde), Da migliorare (arancione) e Scarso (rosso). Perché una pagina riceva il segnale positivo di Page Experience, il 75° percentile delle sessioni reali deve rientrare nella zona verde per tutte e tre le metriche. Il 75° percentile significa che il 75% delle sessioni deve essere sotto la soglia verde — non la media, non il valore mediano. Questo è importante perché la media può essere distorta da un piccolo numero di sessioni molto veloci, mentre il 75° percentile garantisce che anche gli utenti in condizioni peggiori abbiano un'esperienza accettabile. Se una sola delle tre metriche è in rosso per il 25% degli utenti, l'intero segnale Page Experience risulta negativo.
LCP — Largest Contentful Paint: velocità di caricamento percepita
L'LCP misura il tempo necessario perché l'elemento visivo più grande visibile nel viewport venga completamente renderizzato. Nella maggior parte dei casi si tratta dell'immagine hero, del banner principale o del primo blocco di testo grande nella fold. Il target di Google è chiaro: sotto 2,5 secondi è buono, tra 2,5 e 4 secondi è da migliorare, sopra 4 secondi è scarso. L'LCP dipende da quattro fattori principali che si sommano: il tempo di risposta del server (TTFB), il tempo di blocco del rendering da parte di CSS e JavaScript, il tempo di download della risorsa principale e il tempo di rendering nel browser. Ottimizzare l'LCP significa intervenire su tutti e quattro questi fattori in modo coordinato — non basta comprimere le immagini se il server risponde in 800ms.
Le cause più comuni di un LCP lento sono immagini hero non ottimizzate, font web che bloccano il rendering, CSS e JavaScript critici non ottimizzati e hosting lento. Per le immagini, la soluzione più efficace è usare il formato WebP o AVIF con dimensioni appropriate per ogni breakpoint, combinato con l'attributo loading="eager" e il fetchpriority="high" sull'elemento che diventerà l'LCP. Molti sviluppatori commettono l'errore di applicare loading="lazy" a tutte le immagini, inclusa quella hero: questo ritarda ulteriormente il caricamento dell'LCP element perché il browser non inizia il download finché l'immagine non è vicina al viewport. Un'altra ottimizzazione fondamentale è il preload: aggiungere <link rel="preload" as="image"> nel <head> dice al browser di scaricare l'immagine LCP immediatamente, prima ancora di aver parsato tutto il DOM. Per i font, usare font-display: swap o font-display: optional evita il blocco del rendering. Il font-display: optional è la scelta più aggressiva: se il font non è disponibile in circa 100ms, il browser usa il fallback e non cambia mai — elimina completamente il flash di testo invisibile (FOIT) ma può risultare in font inconsistenti tra le pagine.
Buono: ≤ 2,5 secondi — segnale positivo per il ranking
Da migliorare: tra 2,5s e 4s — neutro, da ottimizzare
Scarso: > 4 secondi — segnale negativo, priorità alta di intervento
Il valore si misura al 75° percentile delle sessioni reali degli utenti.
INP — Interaction to Next Paint: reattività alle interazioni
L'INP (Interaction to Next Paint) ha sostituito il FID (First Input Delay) come metrica di interattività nel marzo 2024. Mentre il FID misurava solo il ritardo del primo input, l'INP misura la latenza di tutte le interazioni dell'utente con la pagina — clic, tap e pressioni di tasti — e restituisce il 98° percentile di queste latenze come punteggio finale. In pratica, è la misura di quanto è reattivo il tuo sito quando l'utente ci interagisce attivamente. I target sono: sotto 200ms è buono, tra 200ms e 500ms è da migliorare, sopra 500ms è scarso. L'INP è particolarmente problematico nei siti con molto JavaScript: ogni evento click deve attendere che il main thread del browser sia libero prima di essere processato. Se hai script pesanti che girano in background, un click su un bottone può sembrare "bloccato" per mezzo secondo o più, anche se tecnicamente il browser ha registrato l'evento.
Le cause più comuni di INP elevato sono long tasks JavaScript (task che bloccano il main thread per più di 50ms), event listener pesanti, re-layout massicci causati da lettura e scrittura alternata del DOM, e librerie di terze parti non ottimizzate come widget chat, analytics pesanti e A/B testing. Per migliorare l'INP è necessario dividere i long task in chunk più piccoli usando scheduler.yield() o setTimeout, spostare la logica pesante nei Web Workers (thread separati che non bloccano il UI thread), e ridurre o differire il caricamento di script di terze parti. Google consiglia di usare il Chrome DevTools Performance Insights panel per identificare i long tasks: ogni barra rossa nel flame chart indica un task che supera i 50ms. L'approccio più efficace è quello di profilare l'applicazione durante un'interazione reale — ad esempio, registrare cosa succede quando l'utente clicca sul menu di navigazione o su un bottone di aggiunta al carrello — e poi ottimizzare i task più lunghi uno alla volta.
CLS — Cumulative Layout Shift: stabilità visiva della pagina
Il CLS misura quanto il layout della pagina si sposta in modo inaspettato durante il caricamento e l'uso. Ogni volta che un elemento si sposta senza che l'utente abbia fatto nulla, contribuisce al CLS score. Il punteggio è un valore adimensionale calcolato come prodotto della fraction dell'area impattata moltiplicata per la distanza di spostamento. Un CLS di 0,1 o meno è considerato buono, tra 0,1 e 0,25 è da migliorare, sopra 0,25 è scarso. Il caso classico di CLS elevato è il bottone su cui stai per cliccare che si sposta perché sopra di lui compare un banner pubblicitario o un'immagine che finisce di caricarsi. Questo è particolarmente frustrante su mobile e può portare l'utente a cliccare accidentalmente su link sbagliati.
Le cause più comuni di CLS sono immagini senza dimensioni esplicite (il browser non sa quanto spazio riservare finché l'immagine non è caricata), annunci pubblicitari a dimensione variabile, font web che sostituiscono il fallback e cambiano la dimensione del testo, e contenuti iniettati dinamicamente da JavaScript sopra contenuto esistente. La soluzione principale per le immagini è specificare sempre gli attributi width e height nel tag HTML: questo permette al browser di calcolare in anticipo l'aspect ratio e riservare lo spazio corretto. Per gli annunci, usa contenitori con dimensioni minime fisse. Per i font, usa size-adjust e ascent-override nelle @font-face declarations per ridurre il layout shift causato dalla sostituzione del font. Un'altra tecnica efficace è lo skeleton loading: mostrare placeholder grigi della stessa dimensione del contenuto che sta per arrivare riduce drasticamente il CLS perché lo spazio è già riservato nel layout.
- Basati su utenti reali Chrome
- Riflettono condizioni reali di rete e dispositivo
- Disponibili in Search Console e PageSpeed
- Aggiornati ogni 28 giorni su base rolling
- Usati da Google per il ranking effettivo
- Ambiente controllato e riproducibile
- Disponibili immediatamente dopo ogni modifica
- Utili per debugging e sviluppo locale
- Non usati direttamente per il ranking
- Possono divergere molto dai dati reali
Strumenti per misurare i Core Web Vitals
Google PageSpeed Insights è il punto di partenza: inserisci l'URL e ottieni sia i dati di campo (se disponibili nel CrUX) sia i dati di laboratorio Lighthouse. La sezione più importante è quella dei dati di campo, perché mostra i valori reali al 75° percentile per LCP, INP e CLS. La sezione di laboratorio è utile per il debugging ma non riflette necessariamente quello che Google vede. Per una vista aggregata su tutte le pagine del sito, usa Google Search Console: il report "Esperienza della pagina" mostra quante URL del tuo sito sono nel verde, in arancione e in rosso per ogni metrica, con la possibilità di vedere i dettagli per gruppi di URL simili. È lo strumento più importante perché usa gli stessi dati che Google usa per il ranking. Il terzo strumento fondamentale è Chrome DevTools: il pannello Performance ti permette di registrare e analizzare esattamente cosa succede durante il caricamento e durante le interazioni, identificando long tasks, risorse bloccanti e layout shifts con precisione chirurgica.
Per il monitoraggio continuo, considera di installare la web-vitals JavaScript library di Google direttamente nel tuo sito: raccoglie le metriche degli utenti reali e le invia al tuo sistema di analytics, permettendoti di vedere i valori reali segmentati per pagina, dispositivo e tipo di connessione. Questo è molto più utile di fare test PageSpeed una volta al mese: ti permette di individuare regressioni immediatamente dopo un aggiornamento del sito e di capire quali pagine hanno problemi che non si manifestano nei test di laboratorio. Strumenti come Vercel Speed Insights, Sentry Performance e Datadog RUM offrono già questa funzionalità integrata se stai usando quelle piattaforme.
Come ottimizzare LCP: tecniche pratiche per sviluppatori e non
Converti in WebP o AVIF, ridimensiona all'effettiva dimensione di display, aggiungi fetchpriority="high", rimuovi loading="lazy" se presente, aggiungi il preload nel <head>. Risparmio tipico: 0,5–1,5 secondi di LCP.
Usa una CDN per servire contenuto statico dal punto geograficamente più vicino all'utente. Abilita HTTP/2 e la compressione Brotli. Se usi WordPress, installa un plugin di caching come WP Rocket o W3 Total Cache. Risparmio tipico: 0,2–0,8 secondi di TTFB.
Aggiungi defer o async a tutti gli script non critici. Estrai il CSS critico (above-the-fold) e inseriscilo inline nel <head>, caricando il resto del CSS in modo asincrono. Strumenti come Critical o Penthouse automatizzano questa operazione. Risparmio tipico: 0,3–1,0 secondi.
Usa font-display: swap nelle dichiarazioni @font-face. Precarica i font critici con <link rel="preload" as="font">. Considera di usare i font di sistema come fallback primario se la differenza visiva è minima. Risparmio tipico: 0,1–0,5 secondi.
Errori comuni che distruggono i Core Web Vitals
loading="lazy" all'immagine principale della pagina è uno degli errori più frequenti e dannosi. Il browser ritarda il download dell'immagine finché non è vicina al viewport — ma l'immagine hero È già nel viewport al caricamento. Risultato: l'LCP peggiora significativamente. L'immagine hero deve sempre avere loading="eager" (o nessun attributo loading) e fetchpriority="high".<script> normale bloccano il parsing del DOM. Ogni kilobyte di JavaScript sincrono nell'<head> ritarda sia l'LCP sia l'INP. Usa sempre defer o async per gli script non critici, e considera di differirli ulteriormente con un timeout di 3-5 secondi dopo l'evento load per gli script non essenziali come le chat.Core Web Vitals per siti WordPress
WordPress è la piattaforma più usata al mondo e anche quella con i problemi di performance più diffusi, spesso causati da temi pesanti, plugin mal ottimizzati e hosting inadeguato. Il problema principale è che WordPress di default carica decine di script e stili anche quando non sono necessari per la pagina visualizzata — ogni plugin aggiunge le sue risorse indiscriminatamente. La prima ottimizzazione da fare è disabilitare il caricamento di risorse non utilizzate: plugin come Asset CleanUp o Perfmatters permettono di disabilitare selettivamente script e stili per specifiche pagine. La seconda priorità è il caching: un plugin come WP Rocket o LiteSpeed Cache (se il tuo hosting usa il server LiteSpeed) riduce drasticamente i tempi di risposta del server generando versioni statiche HTML delle pagine dinamiche. Per le immagini, il plugin Imagify o ShortPixel convertono automaticamente in WebP e comprimono le immagini al caricamento. Infine, considera un hosting gestito WordPress come Kinsta, WP Engine o Cloudways: costano di più dell'hosting condiviso ma includono già CDN, caching avanzato e server ottimizzati per PHP, e spesso è la differenza tra un LCP di 4 secondi e uno di 1,8 secondi.
L'impatto dei Core Web Vitals sul ranking: quanto contano davvero?
Da quando Google ha confermato i Core Web Vitals come fattore di ranking, molti SEO si sono chiesti quanto pesino realmente rispetto ad altri segnali. La risposta onesta è: meno della relevanza dei contenuti e dei backlink, ma abbastanza da fare la differenza in mercati competitivi. Google ha dichiarato che i Core Web Vitals sono un tiebreaker — a parità di contenuto e autorità, il sito con performance migliori ha un vantaggio. In pratica, questo significa che se il tuo sito è scadente su tutti e tre i CWV e i tuoi competitor principali sono nel verde, stai lasciando posizioni sul tavolo. Viceversa, ottimizzare i CWV non farà miracoli se il tuo contenuto non risponde all'intento di ricerca dell'utente o se non hai link di autorità. La strategia corretta è trattare i Core Web Vitals come un prerequisito di qualità: devono essere nel verde per non penalizzarti, poi il ranking lo costruisci con contenuti e link building. Gli studi di correlazione mostrano che i siti nelle prime posizioni tendono ad avere CWV migliori dei siti nelle posizioni inferiori — ma la causalità non è semplice da isolare. Quel che è certo è che l'esperienza utente migliore porta a più tempo sul sito, meno rimbalzi e più conversioni — benefici che vanno ben oltre il solo fattore ranking.
Ottimizzare i Core Web Vitals richiede un'analisi tecnica accurata e interventi mirati: non esiste una ricetta universale, ogni sito ha le sue criticità specifiche. Se vuoi un'analisi professionale delle performance del tuo sito con un piano d'azione concreto, scopri il servizio SEO oppure contattami direttamente per una consulenza.
