I Core Web Vitals sono tre metriche che misurano caricamento (LCP), reattività (INP) e stabilità visiva (CLS) di una pagina. Per essere considerate «buone» servono un LCP entro 2,5 secondi, un INP entro 200 millisecondi e un CLS non superiore a 0,1, valutati al 75° percentile delle visite. Google si basa sui dati raccolti sul campo, quelli di utenti reali.
In breve:
- La valutazione di Google usa dati sul campo al 75° percentile: almeno tre visite su quattro devono rispettare le soglie previste.
- Usa PageSpeed Insights per confrontare dati simulati e reali; Lighthouse individua i problemi, ma per la valutazione di Google contano le visite effettive.
- Search Console raggruppa URL con esperienze simili e può escludere i siti poco trafficati, perché mancano dati sufficienti; verifica le singole pagine con PageSpeed Insights.
- Per migliorare l’LCP comprimi l’immagine principale; per l’INP rimanda gli script non essenziali; per il CLS riserva spazio a immagini e iframe.
Indice
- Cosa misurano LCP, INP e CLS nella pratica
- Perché i Core Web Vitals contano per UX, conversioni e SEO
- Come misurare i Core Web Vitals: strumenti e metodo
- Come leggere il report Core Web Vitals in Search Console
- Interventi pratici per migliorare LCP, INP e CLS
- Piano operativo: dall'audit al monitoraggio continuo
- Design e performance non sono in conflitto
- Facciamo noi l'audit dei tuoi Core Web Vitals
- Domande frequenti
- Fonti
Cosa misurano LCP, INP e CLS nella pratica
Ogni metrica fotografa un momento diverso dell'esperienza: quando il contenuto principale compare, quanto la pagina risponde ai tuoi gesti e quanto resta ferma mentre la leggi.
LCP (Largest Contentful Paint) misura il tempo necessario per mostrare l'elemento più grande visibile nella schermata iniziale. Di solito è un'immagine aero, un video di copertina o un grosso blocco di testo. Conta perché coincide con il momento in cui chi visita pensa «la pagina è pronta».
INP (Interaction to Next Paint) ha sostituito FID. Osserva le interazioni durante la visita (clic, tocchi, pressioni di tasti) e misura quanto passa prima che lo schermo mostri una reazione. Prende in considerazione il caso peggiore tra le interazioni osservate, quindi le interazioni lente possono peggiorare il punteggio.
CLS (Cumulative Layout Shift) somma gli spostamenti inattesi degli elementi mentre la pagina si carica. Le cause tipiche sono immagini senza attributi di larghezza e altezza, iframe che si espandono, banner inseriti sopra il testo e font che cambiano dimensione al caricamento.
Ecco i valori di riferimento, sempre al 75° percentile:
- LCP: buono fino a 2,5 secondi, scadente oltre 4 secondi.
- INP: buono fino a 200 millisecondi, scadente oltre 500 millisecondi.
- CLS: buono fino a 0,1, scadente oltre 0,25.
Il 75° percentile significa che almeno tre visite su quattro devono rientrare nella soglia «Buono»: lo dichiara web.dev nel descrivere come sono state definite le soglie. Non basta quindi un test fortunato sul tuo computer veloce: serve che la maggior parte delle persone reali abbia un'esperienza buona.
Perché i Core Web Vitals contano per UX, conversioni e SEO
L'iniziativa Web Vitals nasce per concentrare l'attenzione sui pochi segnali con il maggiore impatto sull'utente, permettendo ai proprietari dei siti di decidere sui dati e non per intuizione. Per chi gestisce un sito aziendale il legame con il business è diretto: una pagina lenta o instabile fa perdere pazienza proprio a chi stava per compilare un modulo o richiedere un preventivo.
Le cifre più citate nella letteratura pratica, riprese da una lezione di WordPress Learn, vanno lette come ordini di grandezza e non come promesse:
- un sito lento può spingere gli utenti ad abbandonarlo;
- un ritardo può ridurre le conversioni;
- il 47% dei consumatori si aspetta un caricamento in 2 secondi o meno.
Un ritardo di un solo secondo può costare il 7% delle conversioni, secondo le statistiche riportate da WordPress Learn: per un sito che vive di richieste di contatto, ogni decimo di secondo ha un effetto sul fatturato.
Sul fronte SEO, Google valuta le metriche con dati sul campo (CrUX) e con il criterio del 75° percentile. Questo spiega perché un punteggio ottimo in laboratorio non basta se gli utenti reali, magari su smartphone e connessioni mediocri, vivono un'altra storia.
Quando conviene dare priorità alle prestazioni? Quando i contenuti sono già solidi, le pagine chiave ricevono traffico e la percentuale di abbandono è alta. Se invece mancano contenuti o pagine mirate, parti da lì: la velocità amplifica una buona strategia, non la sostituisce.
Come misurare i Core Web Vitals: strumenti e metodo
Prima di intervenire devi capire quale strumento risponde a quale domanda. PageSpeed Insights combina dati di laboratorio e dati sul campo (CrUX) e offre analisi separate per mobile e desktop, con suggerimenti pratici. Il report Core Web Vitals di Search Console dà invece una panoramica storica basata su utenti reali. Chrome DevTools e Lighthouse servono al de bug in laboratorio, mentre la libreria web-vitals raccoglie le metriche direttamente dai tuoi visitatori.
La differenza tra lab e field è il punto che crea più confusione. I dati di laboratorio vengono da un test simulato, ripetibile e perfetto per capire cosa non va. I dati sul campo rappresentano l'esperienza reale e spesso divergono dai primi: Google privilegia questi ultimi per il ranking.
Come procedere, passo dopo passo:
- Apri PageSpeed Insights e inserisci l'URL della pagina da analizzare.
- Leggi per primi i dati sul campo: se la pagina non ne ha abbastanza, il tool lo segnala.
- Confronta con i risultati di laboratorio e segna le opportunità proposte, divise per LCP, INP e CLS.
- Riproduci il problema in Chrome DevTools, per esempio registrando una sessione nel pannello Performance.
- Installa la libreria web-vitals e invia LCP, INP e CLS al tuo strumento di analytics, come mostra il percorso di Google dedicato ai Web Vitals.
- Segmenta i dati per dispositivo e per pagina, così capisci dove il problema pesa di più.
Un consiglio: non fermarti al punteggio complessivo di Lighthouse: apri sempre il dettaglio delle singole metriche e confrontale con i dati sul campo, perché è lì che si decide la valutazione di Google.
Se l'hosting o la rete sono il collo di bottiglia, il tema supera il frontend: un approfondimento sulle architetture cloud e ibride aiuta a ragionare su server e infrastruttura.
Come leggere il report Core Web Vitals in Search Console
Il report non elenca ogni URL indicizzato. Search Console raggruppa le pagine con esperienze simili e omette i gruppi che non hanno una quantità minima di dati CrUX. Per un sito a basso traffico significa che alcune pagine potrebbero non comparire affatto: non è un errore, è mancanza di campione.
Ogni gruppo riceve un'etichetta in base al 75° percentile:
- Buono: tutte e tre le metriche rientrano nelle soglie.
- Richiede miglioramenti: almeno una metrica è fuori soglia ma non nel range scadente.
- Scadente: almeno una metrica supera la soglia critica.
Per usare il report con metodo, parti dai gruppi segnati come scadenti e controlla quali modelli di pagina contengono: una scheda prodotto, un articolo del blog, la Hoè. Spesso il problema è nel templare e correggerlo può migliorare più pagine in un colpo solo. Poi apri uno degli URL del gruppo in PageSpeed Insights e individua la metrica responsabile. Infine, dopo l'intervento, usa la funzione di convalida e attendi: i dati sul campo non si aggiornano immediatamente.
Interventi pratici per migliorare LCP, INP e CLS
Il confronto più utile è tra interventi veloci e interventi strutturali, metrica per metrica. Le West pracrite indicate da Cloudflare (immagini ottimizzate, caching efficiente, codice minimizzato e CDN) coprono buona parte dei quick wins.
- LCP, quick win: comprimi l'immagine aero e usa formati moderni come WebP o AVIF. Dai priorità di caricamento all'elemento principale, senza ritardarlo con lazo loading.
- LCP, intervento medio: abilita il caching, riduci i tempi di risposta del server e servi i file da una CDN più vicina agli utenti.
- INP, quick win: togli o rimanda gli script di terze parti non essenziali, come budget di chat, cracker duplicati e pixel inutilizzati.
- INP, intervento strutturale: spezza i long task di JavaScript, applica il code-splitting e sposta i calcoli pesanti in web worker, così il thread principale resta libero di rispondere ai tocchi.
- CLS, quick win: dichiara larghezza e altezza di immagini e iframe, in modo che il browser riservi lo spazio prima del caricamento.
- CLS, intervento medio: evita di inserire banner o contenuti sopra quelli già visibili e gestisci il caricamento dei font con regole che limitino lo spostamento del testo.
Le priorità cambiano a seconda del sito. Su uno show con molte immagini l'LCP è quasi sempre il primo fronte. Su un sito pieno di strumenti di tracciamento e moduli dinamici l'INP è il candidato. Sulle pagine con pubblicità o contenuti incorporati il CLS tende a essere il più ostico.
Un consiglio: cambia una sola cosa alla volta e misura prima e dopo: se modifichi immagini, script e font insieme, non saprai mai quale intervento ha funzionato.
Gli interventi strutturali richiedono più tempo e coinvolgono sviluppo e design insieme: un refactor del codice che rallenta la grafica non serve a nessuno. Per questo conviene pianificarli dopo aver incassato i quick wins, che di solito bastano a spostare più di una pagina dalla fascia scadente a quella intermedia.
Piano operativo: dall'audit al monitoraggio continuo
Una Roma semplice funziona meglio di un piano perfetto. La sequenza è questa: audit, priorità, implementazione, test, monitoraggio.
- Fai un audit con PageSpeed Insights e Search Console sui modelli di pagina principali.
- Dai priorità alle pagine che portano più traffico o più richieste di contatto.
- Implementa prima i quick wins, poi gli interventi medi e solo dopo quelli strutturali.
- Verifica in laboratorio e poi attendi i dati sul campo.
- Monitora ogni settimana o ogni mese i valori al 75° percentile.
| Fase | Intervento tipico | Tempistica indicativa |
|---|---|---|
| Quick win | Compressione immagini, dimensioni dichiarate, caching | Pochi giorni |
| Intervento medio | CDN, riduzione script di terze parti, gestione font | Alcune settimane |
| Intervento strutturale | Refactor JavaScript, riorganizzazione degli asset | Uno o più mesi |
Il criterio di successo è chiaro: LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1 al 75° percentile, con le pagine che portano più valore per prime.
Design e performance non sono in conflitto
Nel nostro lavoro vediamo spesso lo stesso errore: il sito viene disegnato prima e ottimizzato dopo, con un'immagine a tutta pagina pesantissima e animazioni che bloccano il thread principale. Noi facciamo il contrario: estetica, usabilità e velocità si decidono insieme, fin dalla scelta dei font e dei formati delle immagini. Un design bello ma lento non converte, e una pagina veloce ma anonima nemmeno. Il nostro obiettivo è trasformare i miglioramenti tecnici in richieste di contatto misurabili. Per vedere come impostiamo i progetti puoi consultare il nostro portfolio.
— Purple
Facciamo noi l'audit dei tuoi Core Web Vitals
Se preferisci delegare, ci occupiamo noi dell'intero percorso: sviluppo e ottimizzazione di siti web, design orientato alla conversione e Smarketing, il nostro servizio che unisce strategia di marketing e ottimizzazione. Un nostro audit parte dall'analisi dei dati sul campo e di laboratorio, individua le pagine critiche e si chiude con un piano operativo ordinato per priorità, così sai cosa fare per primo e cosa può aspettare.
Se vuoi capire a che punto è il tuo sito, contattaci e richiedi un audit dei Core Web Vitals.
Domande frequenti
Cosa sono i Core Web Vitals?
Sono tre metriche che misurano la qualità dell'esperienza su una pagina: LCP per il caricamento, INP per la reattività e CLS per la stabilità visiva. Google le valuta al 75° percentile delle visite reali e le soglie «buone» sono LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1.
Come posso misurare la velocità del mio sito web?
Il modo più rapido è PageSpeed Insights, che mostra insieme dati di laboratorio e dati sul campo. Per un quadro storico basato su utenti reali usa il report Core Web Vitals di Search Console. Per la raccolta interna puoi installare la libreria web-vitals e inviare i valori al tuo strumento di analytics.
Meglio i dati di laboratorio o quelli sul campo?
Servono entrambi, ma per scopi diversi. I dati di laboratorio aiutano a trovare e riprodurre i problemi, quelli sul campo mostrano l'esperienza vera degli utenti e sono quelli che Google privilegia per la valutazione. Se i due valori divergono, fidati dei dati sul campo.
Perché il mio sito non compare nel report di Search Console?
Il report omette i gruppi di URL senza una quantità minima di dati CrUX, quindi i siti a basso traffico possono risultare incompleti. Nel frattempo puoi usare PageSpeed Insights per le singole pagine e la libreria web-vitals per raccogliere dati propri.
Fonti
- Web
- Developers
- Suggerimenti per migliorare la velocità del sito | Come velocizzare i siti Web | Cloudflare