INDICE
Antonio Ilacqua
Web Designer & Consulente SEO · Milazzo (ME)
I Core Web Vitals sono tre metriche che Google usa per valutare la qualità dell'esperienza utente di un sito web. Dal 2021 sono diventati fattori ufficiali di ranking: un sito lento o instabile viene penalizzato nelle SERP rispetto a un sito con prestazioni eccellenti, a parità di contenuto. Nel 2026, con soglie ancora più stringenti rispetto al lancio iniziale, ignorarli significa lasciare posizioni ai competitor che ci hanno lavorato.
Dato Google I/O 2023: le pagine che superano le soglie dei Core Web Vitals hanno una probabilità 24% più alta di non essere abbandonate dall'utente prima del caricamento. Meno abbandoni = più tempo sul sito = segnale positivo per il ranking.
1. Cosa sono i Core Web Vitals
Tre metriche, tre aspetti distinti dell'esperienza utente. Ognuna ha una soglia precisa che divide "buono" da "da migliorare" da "scarso".
LCP — Largest Contentful Paint
Soglia buona: < 2,5 secondiMisura il tempo che impiega il contenuto principale della pagina (solitamente l'immagine hero o il titolo principale) a comparire sullo schermo. In parole semplici: quanto ci vuole prima che l'utente veda qualcosa di utile. Oltre i 4 secondi è considerato scarso da Google.
INP — Interaction to Next Paint
Soglia buona: < 200 msHa sostituito FID (First Input Delay) a marzo 2024. Misura la reattività della pagina alle interazioni dell'utente: clic su pulsanti, apertura menu, input nei form. Se il sito "si blocca" un attimo dopo che clicchi su qualcosa, è un INP alto. Oltre 500 ms è considerato scarso.
CLS — Cumulative Layout Shift
Soglia buona: < 0,1Misura la stabilità visiva della pagina durante il caricamento. Un CLS alto significa che elementi della pagina si spostano mentre stai leggendo o stai per cliccare — un'esperienza frustrante. Il valore è adimensionale: 0 è perfetto, sopra 0,25 è considerato scarso da Google.
2. Come misurarli gratuitamente
Esistono due tipi di dati per i Core Web Vitals: i dati Lab (simulati da un tool in condizioni controllate) e i dati Field (raccolti da utenti reali che visitano il sito). Per il ranking Google usa esclusivamente i dati Field — i dati Lab sono utili per capire dove intervenire, ma non riflettono l'esperienza reale.
PageSpeed Insights — pagespeed.web.dev
Il punto di partenza più semplice. Inserisci l'URL e ottieni sia i dati Lab (Lighthouse) che i dati Field (Chrome UX Report) per quella pagina. Mostra un punteggio 0–100 e segnala esattamente quali elementi rallentano il sito. Completamente gratuito, nessun account necessario.
Google Search Console — sezione Esperienza → Core Web Vitals
Mostra i dati Field aggregati per tutte le pagine del tuo sito, suddivise in "Buone", "Da migliorare" e "Scarse". È l'unico strumento che ti mostra quante pagine hanno un problema e quali sono le più urgenti da correggere. Dati reali, non simulazioni.
Chrome DevTools — tab Lighthouse
Integrato nel browser Chrome (F12 → Lighthouse). Utile per testare pagine non pubbliche (staging, localhost) o per analisi dettagliate elemento per elemento. Fornisce dati Lab con suggerimenti specifici su cosa ottimizzare e quanto potrebbe migliorare la metrica.
Regola fondamentale: i dati Lab (Lighthouse, PageSpeed) servono per diagnosticare. I dati Field (GSC, Chrome UX Report) sono quelli che Google usa per il ranking. Puoi avere un punteggio Lighthouse alto e comunque avere problemi CWV nei dati Field, se gli utenti reali hanno connessioni lente o dispositivi vecchi.
3. LCP: come migliorarlo
L'LCP è la metrica con l'impatto maggiore sul ranking e spesso quella più facile da migliorare con interventi mirati. Le cause più comuni di un LCP lento sono tre:
- Immagine hero non ottimizzata. Un'immagine da 2–3 MB che viene ridimensionata via CSS è la causa più comune di LCP alto. Soluzione: convertire in formato WebP (fino al 30% più leggero di JPEG a parità di qualità), ridimensionare al display size reale e aggiungere l'attributo
loading="eager"all'immagine hero (non lazy loading per il contenuto above the fold). - Font bloccanti. I font Google caricati senza
display=swapbloccano il rendering del testo fino al caricamento completo. Aggiungere&display=swapall'URL del font e usarerel="preload"riduce sensibilmente l'LCP. - Server lento (TTFB alto). Se il server impiega più di 600ms per rispondere (TTFB — Time to First Byte), l'LCP ne risente direttamente. Soluzione: CDN (Content Delivery Network) per servire i file statici dal nodo geograficamente più vicino all'utente, e hosting con PHP/server-side caching abilitato.
Per approfondire ogni ottimizzazione con esempi di codice specifici, la guida ufficiale di Google è disponibile su web.dev/lcp.
4. INP e CLS: le metriche più trascurate
INP e CLS vengono spesso ignorati perché meno "visibili" di un caricamento lento. Eppure sono quelli che creano le esperienze più frustranti per l'utente.
Come migliorare l'INP: la causa principale è il JavaScript pesante eseguito nel thread principale del browser. Ogni volta che l'utente interagisce con un elemento, il browser deve aspettare che il JS in esecuzione finisca prima di rispondere. Soluzioni pratiche: ridurre i plugin inutili (in WordPress, ogni plugin attivo aggiunge JS alla pagina), differire il caricamento degli script non critici con defer o async, e usare event delegation invece di listener multipli sullo stesso tipo di evento.
Come migliorare il CLS: il layout shift avviene quando il browser carica un elemento (immagine, font, banner pubblicitario) senza conoscerne le dimensioni in anticipo e deve riorganizzare il layout. Soluzioni: specificare sempre gli attributi width e height per ogni immagine e iframe, riservare spazio fisso per banner e widget caricati dinamicamente, e non inserire contenuto dinamico sopra il testo esistente dopo il caricamento iniziale.
Per una guida completa su come la velocità del sito influisce sul ranking SEO — con casi concreti e ottimizzazioni step-by-step — leggi: Velocità sito web e SEO: la guida pratica.
5. Priorità: da dove iniziare
Se stai partendo da zero con i Core Web Vitals, questa è la sequenza di azioni che raccomando — ordinata per impatto sul ranking e facilità di esecuzione:
- Prima: misura (PageSpeed Insights + GSC). Non intervenire al buio. Identifica quali pagine hanno problemi Field e quali metriche sono critiche. 15 minuti di analisi salvano ore di ottimizzazioni inutili.
- Secondo: ottimizza l'LCP. Ha il peso maggiore sul ranking tra i tre. Le ottimizzazioni delle immagini hero e del TTFB danno il ritorno più rapido sull'investimento di tempo.
- Terzo: correggi il CLS. Più facile da risolvere dell'INP, spesso basta aggiungere dimensioni alle immagini. L'impatto visivo è immediato e apprezzato dagli utenti su mobile.
- Quarto: lavora sull'INP. Richiede analisi più tecnica del JavaScript. Inizia rimuovendo plugin inutili in WordPress — è il miglioramento più semplice con impatto maggiore sulla maggior parte dei siti.
Secondo HTTP Archive (Web Almanac 2024), solo il 51% delle pagine analizzate supera le soglie "buono" per tutti e tre i Core Web Vitals. Il CLS è la metrica con il più alto tasso di superamento, l'INP quella con il più basso. Questo significa che lavorare su INP ti differenzia dalla maggioranza dei siti competitor che non ci hanno ancora messo mano.
FONTI
- Google Search Central, Web Vitals – web.dev/vitals
- Google I/O 2023, Core Web Vitals session – io.google/2023
- HTTP Archive, Web Almanac 2024 – almanac.httparchive.org
- Chrome UX Report – developer.chrome.com/docs/crux
Il tuo sito supera i Core Web Vitals?
Analizzo gratuitamente le performance del tuo sito e ti dico cosa rallenta il ranking.