Core Web Vitals

Cosa sono i Core Web Vitals

I Core Web Vitals sono le misure con cui Google valuta la qualità dell'esperienza su una pagina. Sono arrivate nel 2020 e contano per il posizionamento dal 2021, quindi fanno parte della SEO tecnica. Il pregio è che misurano quello che capita alle persone vere sul tuo sito, non una simulazione.

Guardano tre cose che corrispondono a tre fastidi che conosci bene:

• Velocità di caricamento (LCP)
• Interattività (INP)
• Stabilità visiva (CLS)

Queste metriche fanno parte del più ampio sistema di segnali "Page Experience" che Google utilizza per valutare la qualità complessiva di una pagina, insieme a HTTPS, assenza di interstitial invasivi e compatibilità mobile.

«I Core Web Vitals mettono un numero su tre fastidi quotidiani: la pagina che non compare, il pulsante che non risponde, il testo che si sposta mentre stai leggendo.»

LCP: Largest Contentful Paint

Il Largest Contentful Paint (LCP) misura il tempo necessario per rendere visibile l'elemento di contenuto più grande nel viewport della pagina. Questo elemento è tipicamente un'immagine hero, un video o un blocco di testo prominente.

Le cause più comuni di un LCP lento includono tempi di risposta del server elevati, risorse CSS e JavaScript che bloccano il rendering, tempi di caricamento delle immagini e rendering lato client. La velocità del sito è strettamente legata al miglioramento dell'LCP.

Nella pratica, il primo passo è identificare quale sia l'elemento LCP della pagina: PageSpeed Insights e Chrome DevTools lo evidenziano esplicitamente. Una volta individuato, l'obiettivo è renderlo visibile il prima possibile, ad esempio precaricando l'immagine hero con <link rel="preload"> ed evitando il lazy-loading proprio su quell'elemento. Per le pagine di un e-commerce o di un blog, dove l'immagine principale è spesso l'elemento LCP, servire formati moderni come WebP o AVIF e dimensionare correttamente le immagini può ridurre i tempi anche di diversi secondi.

INP: Interaction to Next Paint

L'Interaction to Next Paint (INP) ha sostituito il FID (First Input Delay) come metrica di interattività a marzo 2024. L'INP misura la latenza complessiva delle interazioni dell'utente con la pagina, considerando tutti i click, i tap e le interazioni da tastiera durante l'intera sessione.

A differenza del FID che misurava solo la prima interazione, l'INP tiene conto di tutte le interazioni durante la visita, fornendo un quadro più completo della reattività della pagina. Le principali cause di un INP scarso sono i long task JavaScript, il main thread bloccato e gestori di eventi troppo complessi.

L'INP è particolarmente critico sui siti ricchi di JavaScript, come single page application, dashboard e store online costruiti con framework moderni. Quando l'utente fa tap su un pulsante "aggiungi al carrello" o apre un menu, ogni millisecondo di attesa prima del successivo rendering visibile peggiora la percezione di lentezza. In ottica pratica conviene misurare l'INP sul traffico mobile reale, dove i dispositivi meno potenti amplificano il costo dei task JavaScript pesanti.

CLS: Cumulative Layout Shift

Il Cumulative Layout Shift (CLS) misura la stabilità visiva della pagina, quantificando quanto gli elementi si spostano inaspettatamente durante il caricamento. Un CLS elevato causa un'esperienza utente frustrante, ad esempio quando un pulsante si sposta proprio mentre l'utente sta per cliccarlo.

Le cause più frequenti di CLS elevato sono immagini e video senza dimensioni specificate, annunci pubblicitari che si caricano dinamicamente, font web che causano FOIT/FOUT e contenuti iniettati dinamicamente sopra il contenuto esistente.

Il CLS è spesso la metrica più semplice da correggere e quella con il maggior impatto sulla percezione di affidabilità del sito: basta riservare in anticipo lo spazio per ogni elemento che si caricherà in un secondo momento. In termini concreti, significa indicare sempre gli attributi width e height (o aspect-ratio) sulle immagini, definire un'altezza minima per i contenitori di banner e widget di terze parti, e caricare i font con strategie che evitino lo spostamento del testo. Su pagine con molti contenuti dinamici, anche un piccolo accorgimento riduce il rischio che l'utente clicchi per errore sull'elemento sbagliato.

Come misurarli

Gli strumenti si dividono in due famiglie, dati di campo (persone vere) e dati di laboratorio (simulazioni). Servono entrambi, e quando non concordano ha ragione il campo:

• Google Search Console: report "Core Web Vitals" con dati di campo aggregati per tutte le pagine del sito
• PageSpeed Insights: analisi dettagliata con dati di campo (CrUX) e di laboratorio (Lighthouse)
• Chrome DevTools: strumenti di sviluppo del browser per analisi di laboratorio dettagliate
• Lighthouse: audit automatizzato disponibile in Chrome DevTools e come tool standalone
• Chrome UX Report (CrUX): dataset pubblico con dati di campo accessibile tramite BigQuery
• Web Vitals Extension: estensione Chrome per monitorare i CWV in tempo reale durante la navigazione

Una regola pratica per interpretare i dati: usa gli strumenti di laboratorio (Lighthouse, DevTools) per fare diagnosi e testare le modifiche in modo ripetibile, perché restituiscono risultati controllati e immediati; affidati invece ai dati di campo (Search Console, CrUX) per capire come stanno realmente le cose per i tuoi utenti, perché sono questi a influenzare il ranking. Spesso un punteggio di laboratorio ottimo convive con dati di campo mediocri: in quel caso il problema riguarda dispositivi reali, connessioni lente o configurazioni che il test simulato non riproduce.

Come ottimizzarli

Cosa si fa per ognuna delle tre misure:

Ottimizzare l'LCP

• Ottimizzare il Time to First Byte (TTFB) del server
• Utilizzare una CDN per ridurre la latenza
• Implementare il preload per le risorse critiche (immagini hero, font)
• Ottimizzare e comprimere le immagini (formati WebP/AVIF)
• Eliminare CSS e JavaScript render-blocking

Ottimizzare l'INP

• Ridurre il tempo di esecuzione dei long task JavaScript
• Utilizzare requestAnimationFrame e requestIdleCallback per suddividere i task
• Minimizzare il lavoro del main thread
• Utilizzare Web Workers per operazioni pesanti
• Ottimizzare i gestori di eventi e ridurre la complessità del DOM

Ottimizzare il CLS

• Specificare sempre le dimensioni (width/height) per immagini e video
• Riservare spazio per gli annunci pubblicitari e i contenuti caricati dinamicamente
• Usare font-display: swap con dimensioni di fallback corrispondenti
• Evitare di iniettare contenuti sopra il contenuto esistente
• Utilizzare le proprietà CSS contain e content-visibility

L'ottimizzazione dei Core Web Vitals è un processo iterativo che richiede monitoraggio continuo. Utilizza Google Search Console per tenere sotto controllo i dati di campo e PageSpeed Insights per analisi dettagliate pagina per pagina. Per una panoramica completa sull'ottimizzazione delle performance, consulta la guida sulla velocità del sito.

Perché contano per ranking e conversioni

I Core Web Vitals sono uno dei pochi punti in cui quello che è meglio per chi legge coincide con quello che è meglio per il posizionamento. Sul fronte SEO funzionano da spareggio: a parità di contenuti rilevanti, Google tende a preferire la pagina con l'esperienza migliore, e sulle ricerche molto contese quello sposta. Non sostituiscono il lavoro su SEO On-Page e SEO Tecnica: lo rendono più efficace.

Sul fronte dei soldi è ancora più diretto: pagine più veloci e più stabili fanno scappare meno gente e vendono di più, perché ogni secondo di attesa porta via qualcuno prima che abbia potuto fare qualsiasi cosa. Un consiglio pratico per chi lavora nel marketing: se devi chiedere budget per ottimizzarli, portali come una questione di fatturato invece che come una metrica tecnica, perché è quello che sono, e in quella forma vengono approvati. In più un sito rapido si fa scansionare meglio e regge il lavoro sul mobile.