I Core Web Vitals sono le tre metriche con cui Google misura l'esperienza reale di chi visita una pagina: LCP dice quanto ci mette a comparire il contenuto principale, INP quanto velocemente la pagina risponde a clic e tocchi, CLS quanto resta ferma mentre si carica. Una pagina li supera quando, per almeno il 75% delle visite, LCP resta entro 2,5 secondi, INP entro 200 millisecondi e CLS entro 0,1, secondo le soglie pubblicate su web.dev.
LCP: quando compare la parte che conta
Largest Contentful Paint misura il momento in cui diventa visibile l'elemento più grande nella parte di pagina che vedi appena la apri, di solito l'immagine principale o un blocco di testo. È buono entro 2,5 secondi e scadente oltre 4, le stesse soglie usate dal report Core Web Vitals di Search Console.
Per capire da dove arriva il ritardo, web.dev scompone l'LCP in quattro parti: risposta del server, attesa prima che parta il download della risorsa principale, durata del download, ritardo di visualizzazione. In una pagina ben ottimizzata le due attese pesano poco: la guida all'ottimizzazione dell'LCP indica come riferimento circa il 40% del tempo per il server, circa il 40% per il download e meno del 10% ciascuna per le due attese.
Lo stesso articolo mostra un caso istruttivo: se comprimi l'immagine ma la pagina la mostra solo dopo aver eseguito il JavaScript, il tempo risparmiato si sposta nel ritardo di visualizzazione e l'LCP resta uguale.
INP: quanto passa tra il clic e la risposta
Interaction to Next Paint misura la reattività: per ogni clic, tocco o tasto premuto, il tempo tra l'azione e il momento in cui la pagina mostra una reazione. Tiene conto di tutte le interazioni della visita e riporta la più lenta, scartando un valore anomalo ogni 50 interazioni nelle pagine molto usate. È buono entro 200 millisecondi, scadente oltre 500, come spiega la guida all'INP.
INP ha preso il posto di First Input Delay tra i Core Web Vitals il 12 marzo 2024, come annunciato da Google Search Central. La differenza è sostanziale: FID guardava solo il ritardo della prima interazione, INP guarda l'intera visita, compresi filtri, menu e pulsante aggiungi al carrello.
Ogni interazione ha tre fasi: l'attesa prima che il browser inizi a gestire l'input, l'esecuzione del codice collegato e il tempo per disegnare la reazione a schermo (ottimizzare l'INP). I colpevoli tipici sono le attività lunghe, cioè blocchi di lavoro che occupano il thread principale del browser per più di 50 millisecondi (attività lunghe), gli script di terze parti e le pagine con un numero enorme di elementi HTML.
CLS: perché i contenuti non devono saltare
Cumulative Layout Shift misura quanto si spostano gli elementi visibili senza che tu abbia fatto nulla: il testo che scende mentre leggi, il pulsante che si sposta un attimo prima del tocco. Non è un tempo ma un punteggio, buono entro 0,1 e scadente oltre 0,25, secondo la guida al CLS.
Le cause più comuni, elencate nella guida all'ottimizzazione del CLS, sono immagini, annunci, video incorporati e iframe senza dimensioni dichiarate, contenuti inseriti dopo il caricamento e font web. Per i banner, compreso quello dei cookie, la stessa guida suggerisce di riservare lo spazio in anticipo oppure di sovrapporli ai contenuti invece di spingerli in basso. Gli spostamenti che avvengono entro 500 millisecondi da un'azione dell'utente, per esempio dopo il clic su carica altro, non vengono conteggiati.
Dati reali e test di laboratorio: perché i numeri non coincidono
Google valuta i Core Web Vitals sui dati reali del Chrome User Experience Report (CrUX), raccolti in forma anonima dai browser degli utenti. PageSpeed Insights li mostra in alto, sempre al 75° percentile e su una finestra mobile di quattro settimane; sotto aggiunge un test di laboratorio con Lighthouse, che simula il caricamento su un telefono di fascia media con rete mobile, come spiega la pagina informazioni su PageSpeed Insights.
I due numeri raccontano cose diverse. Il laboratorio è ripetibile e serve a trovare le cause; i dati reali dicono cosa succede a chi usa il sito con telefoni e connessioni diversi. Quando non coincidono, per le decisioni conta il dato reale, come spiega web.dev nell'articolo sulle differenze tra dati di laboratorio e sul campo, che ricorda anche un limite: l'INP richiede interazioni di utenti reali, quindi in laboratorio si usano indicatori indiretti.
Se il sito ha poco traffico, CrUX potrebbe non avere dati: pagine e siti entrano nel dataset solo se sono pubblici e abbastanza visitati, e la soglia esatta non è resa nota (metodologia CrUX). In quel caso puoi raccogliere le metriche dai tuoi visitatori con la libreria web-vitals, come spieghiamo nella guida all'audit di performance.
Quanto pesano sul posizionamento?
Google lo dice in modo esplicito: le metriche Core Web Vitals sono usate dai suoi sistemi di ranking, ma non esiste un singolo indicatore dell'esperienza sulle pagine e la Ricerca cerca sempre di mostrare i contenuti più pertinenti, anche quando l'esperienza è scadente. Lo spiega la pagina sull'esperienza sulle pagine nei risultati di Google.
Nella pratica i Core Web Vitals contano quando per una ricerca esistono molte pagine utili e simili: lì un'esperienza migliore può fare la differenza. Non compensano un contenuto debole, e buoni punteggi non garantiscono la prima posizione, come precisa la stessa pagina.
Perché conviene sistemarli anche se il posizionamento non cambia
Perché una pagina lenta o instabile perde persone prima che arrivino al contenuto. Alcuni casi pubblicati su web.dev lo mostrano con misure controllate: Vodafone ha messo a confronto due versioni della stessa pagina e, con un LCP migliore del 31%, ha registrato l'8% di vendite in più; redBus ha aumentato le vendite di circa il 7% dopo aver lavorato sull'INP.
Sono risultati di singole aziende, non una promessa valida per ogni sito. Indicano però dove guardare: un pulsante aggiungi al carrello che risponde in ritardo, o una landing page di Google Ads che si muove mentre carica, sprecano visite già pagate. Per le pagine delle campagne trovi i dettagli nella guida alla landing page per le ADS.
Da dove iniziare se il report è rosso
Parti dal report Core Web Vitals di Search Console, che raggruppa gli URL simili, mostra per ogni gruppo la metrica peggiore e separa mobile e desktop. Correggi prima il modello di pagina che pesa di più, per esempio schede prodotto, articoli o home page, invece di rincorrere il singolo indirizzo. L'ordine che conviene seguire:
- Verifica su quale metrica e su quale dispositivo fallisce il gruppo di pagine.
- Riproduci il problema in laboratorio, con PageSpeed Insights o con il pannello Prestazioni di Chrome DevTools, che affianca anche i dati reali.
- Trova la causa con la scomposizione della metrica: le quattro parti dell'LCP, le tre fasi dell'INP, gli elementi che si spostano per il CLS.
- Correggi, pubblica e annota la data dell'intervento.
- Avvia la convalida in Search Console, che apre un periodo di monitoraggio di quattro settimane sui dati reali.
Le tecniche per ogni metrica, dalle immagini agli script al server, sono raccolte nella guida su come velocizzare un sito lento. Se stai costruendo un sito nuovo conviene partire da basi che rispettano queste soglie: nei siti che realizziamo in Next.js usiamo next/image, che carica le immagini in differita e usa le dimensioni per riservare lo spazio, e next/font, che ospita i font insieme al sito senza richieste a Google.
Vuoi un sito che nasca dentro queste soglie, invece di inseguirle dopo? Guarda come lavoriamo nella realizzazione di siti web; per tenerle sotto controllo nel tempo c'è il servizio di gestione siti web.
Domande frequenti
I Core Web Vitals sono un fattore di ranking?
Sì, Google conferma che le metriche Core Web Vitals sono usate dai suoi sistemi di ranking. Non sono l'unico segnale e non compensano un contenuto poco pertinente: pesano soprattutto quando molte pagine rispondono bene alla stessa ricerca.
Perché PageSpeed Insights e Search Console mostrano valori diversi?
PageSpeed Insights analizza un singolo URL e affianca un test di laboratorio ai dati reali, mentre Search Console raggruppa pagine simili e usa solo i dati reali. Un indirizzo può essere un'eccezione dentro il suo gruppo.
Il mio sito non ha dati sul campo: cosa significa?
Che il sito, o quella pagina, non ha abbastanza visite di utenti Chrome per entrare nel dataset CrUX. Puoi misurare le metriche sui tuoi visitatori con la libreria web-vitals e usare i test di laboratorio per trovare i problemi.
Il First Input Delay conta ancora?
No. Da marzo 2024 è stato sostituito da INP, che misura la reattività su tutte le interazioni della visita e non solo sulla prima.
Un punteggio alto su PageSpeed Insights basta?
Un punteggio verde in laboratorio è un buon segnale, ma non garantisce che gli utenti reali abbiano un'esperienza buona. Per Google contano i dati sul campo, quindi controlla sempre anche il report Core Web Vitals di Search Console.
