In sintesi: I Core Web Vitals sono tre metriche con cui Google misura l’esperienza reale di chi apre una tua pagina: LCP per la comparsa del contenuto principale, INP per la reattività ai clic, CLS per la stabilità visiva. Le soglie buone sono 2,5 secondi, 200 millisecondi e 0,1, sul 75esimo percentile delle visite vere. Contano per il posizionamento, ma rendono di più sulle conversioni.
Hai speso qualche migliaio di euro per rifare il sito, poi ti arriva uno screenshot di PageSpeed Insights con un cerchio rosso e il numero 41. Ti dicono che è un problema SEO, ma nessuno spiega cosa misuri quel numero.
Il paradosso è che quelle metriche raccontano tutt’altro: non un punteggio, ma quanto tempo un cliente resta a fissare uno schermo bianco, quante volte preme un pulsante che non risponde, quante volte clicca sulla cosa sbagliata perché la pagina si è mossa.
Qui vediamo cosa sono, le tre metriche con soglia e cause, perché PageSpeed e Search Console danno numeri diversi, cosa sistemare su WordPress e in quanto tempo si vedono i risultati.
Tre metriche per una sola domanda: il tuo sito fa perdere tempo?
I Core Web Vitals sono i pochi indicatori con cui Google misura l’esperienza di chi usa una pagina. Oggi sono tre: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Coprono tre momenti: quando la pagina compare, quando la tocchi, mentre la leggi.
La valutazione non usa la media ma il 75esimo percentile delle visite reali, separando mobile e desktop: devi funzionare bene per tre quarti dei visitatori, anche quelli con telefono vecchio e linea lenta.
Google le usa perché sono l’unico pezzo di esperienza misurabile su scala planetaria. Nella documentazione sull’esperienza di pagina scrive che i Core Web Vitals sono usati dai suoi sistemi di ranking, ma anche che non esiste un segnale unico e che buoni risultati nei report non garantiscono di posizionarsi in alto.
LCP: quanto aspetti prima di vedere la cosa per cui sei entrato
Il Largest Contentful Paint misura il tempo tra l’inizio del caricamento e la comparsa dell’elemento visibile più grande della prima schermata, di solito l’immagine di apertura o il titolo. È buono a 2,5 secondi o meno, da migliorare tra 2,5 e 4 secondi, scarso oltre 4 secondi.
Tradotto: è il tempo in cui la persona guarda un rettangolo grigio chiedendosi se il sito funziona. Non è quando la pagina finisce di caricare, è quando capisce di essere arrivata nel posto giusto.
Le cause sono quasi sempre quattro: hosting lento a rispondere, immagine di apertura enorme a piena risoluzione, slider in cima alla pagina (il modo più efficiente per rovinare l’LCP), CSS e font che bloccano il testo.
INP: hai cliccato e non succede niente
L’Interaction to Next Paint misura quanto passa tra un’interazione (clic, tocco, tasto) e il primo aggiornamento visivo mostrato in risposta. È buono a 200 millisecondi o meno, da migliorare tra 200 e 500, scarso oltre 500 millisecondi.
È la metrica più recente. Il 12 marzo 2024 INP ha sostituito il First Input Delay, ritirato dal programma: il FID misurava solo il ritardo della prima interazione e quasi tutti lo superavano. INP guarda invece tutte le interazioni della visita.
L’esperienza la conosci: tocchi il menu su mobile e non si apre, tocchi di nuovo, si apre e si richiude. Oppure premi “Aggiungi al carrello”, non succede niente, premi ancora e ti ritrovi due prodotti. Non è lentezza, è un sito che sembra rotto.
Le cause stanno quasi tutte nel JavaScript: plugin che caricano script ovunque, un widget di chat, tre sistemi di tracciamento, un tema pieno di librerie inutilizzate. Il browser ha un solo thread: mentre esegue quel codice non può rispondere al tuo dito.
Cosa significa in pratica: con un ecommerce o un modulo di contatto l’INP tocca il fatturato, perché peggiora proprio quando l’utente compie l’azione che ti interessa. Su un blog informativo pesa molto meno.
CLS: il pulsante si sposta e clicchi sulla cosa sbagliata
Il Cumulative Layout Shift misura quanto i contenuti si spostano da soli mentre la pagina è già visibile. Non è un tempo ma un punteggio: combina quanta parte dello schermo si muove e di quanto. È buono a 0,1 o meno, da migliorare tra 0,1 e 0,25, scarso oltre 0,25.
L’hanno subita tutti: stai leggendo, si carica un’immagine più in alto e il testo scivola via. Oppure stai per premere “Continua” e compare il banner dei cookie che sposta il pulsante, così accetti un tracciamento che non volevi.
Le cause sono note e quasi tutte evitabili: immagini e video senza larghezza e altezza dichiarate, banner iniettati sopra il contenuto visibile, embed di mappe e recensioni che si ridimensionano da soli, font con proporzioni diverse dal ripiego.
Cosa significa in pratica: il CLS ha il miglior rapporto tra sforzo e risultato. Quasi sempre si sistema dichiarando le dimensioni delle immagini e riservando spazio a ciò che arriva dopo: un lavoro di ore, non di settimane.
Perché PageSpeed ti dà 92 e Search Console dice che vai male
Perché misurano due cose diverse. PageSpeed Insights mostra i dati sul campo, raccolti dai browser di utenti reali, e quelli di laboratorio, generati da una simulazione. Il punteggio da 0 a 100 viene dal laboratorio; Search Console usa solo i dati sul campo.
Il laboratorio esegue un caricamento singolo su un dispositivo simulato di fascia media ed elenca i problemi, quindi serve a capire cosa non va. I dati sul campo arrivano dal Chrome UX Report, l’archivio delle esperienze anonime degli utenti Chrome: come spiega la documentazione di PageSpeed Insights, coprono 28 giorni e riportano il 75esimo percentile.
Il report Segnali web essenziali di Search Console usa questi dati e valuta LCP, INP e CLS. Raggruppa gli URL simili, assegna a ogni gruppo lo stato della metrica peggiore e, quando chiedi la convalida di una correzione, osserva il sito per 28 giorni (guida ufficiale al report).
Cosa significa in pratica: usa il laboratorio per capire cosa correggere e il campo per decidere se il problema esiste. Un 41 con i dati sul campo verdi non è un’emergenza; un 90 con il gruppo in rosso lo è.
Su WordPress l’hosting conta più del plugin miracoloso
Su WordPress la classifica degli interventi che rendono è stabile, e in cima non c’è quasi mai il plugin di ottimizzazione. Ecco l’ordine con cui procedere.
- Hosting: un server lento penalizza ogni pagina e nessun plugin recupera quel ritardo. Sull’LCP è l’intervento più redditizio.
- Immagini moderne e dimensionate: servi WebP o AVIF al posto di JPEG pesanti e carica il file alla misura in cui viene mostrato, non a piena risoluzione.
- Caching: la pagina servita dalla cache salta l’elaborazione PHP e le query al database, invece di essere ricostruita a ogni visita.
- Lazy loading selettivo: rimanda le immagini sotto la prima schermata, ma escludi quella di apertura. Applicarlo anche lì peggiora l’LCP.
- Riduzione dei plugin: ognuno aggiunge codice a ogni pagina, spesso dove non serve. Disinstallare quelli che non usi rende più che ottimizzarli.
- Font: ospitali sul tuo dominio invece di chiamarli da un servizio esterno, limita i pesi a due o tre e imposta un ripiego.
- CSS critico: carica in linea il minimo per disegnare la prima schermata e rimanda il resto.
- Dimensioni esplicite su immagini ed embed: larghezza e altezza sulle immagini, altezza minima riservata a mappe, video e banner. È il rimedio principale al CLS.
- Alleggerimento del JavaScript: togli gli script inutilizzati, carica in ritardo chat e tracciamenti, spezza le operazioni lunghe, come indica la guida ufficiale sull’INP.
Le prime cinque voci sono alla portata di chi gestisce il sito. Le ultime quattro vanno delegate a uno sviluppatore: toccano il tema, l’ordine degli script e il codice di plugin di terze parti, e fatte male rompono il sito. Il quadro completo sulla velocità è nella guida alla velocità del sito web, il contesto dei controlli tecnici nell’articolo su SEO tecnica.
Il 100 su 100 non è un obiettivo di business
I Core Web Vitals sono un fattore di ranking reale ma di peso contenuto. Google mostra un contenuto rilevante anche quando l’esperienza di pagina è mediocre. Sistemare le metriche non ti fa scavalcare chi risponde meglio alla domanda dell’utente.
Il guadagno vero è a valle. Una pagina che compare in due secondi, risponde al tocco e non si muove sotto le dita converte meglio, a prescindere da Google. È lo stesso terreno della conversion rate optimization: togliere attrito invece di aggiungere argomenti.
Per calibrare le aspettative aiuta un numero. Secondo il capitolo sulle prestazioni del Web Almanac 2025 di HTTP Archive, pubblicato a gennaio 2026, solo il 48 per cento dei siti supera tutti e tre i Core Web Vitals su mobile e il 56 per cento su desktop. Metà del web sta sotto la soglia: non sei in ritardo, sei nella media.
Sui tempi mettiti l’animo in pace. Siccome la valutazione si basa su 28 giorni di dati reali, dopo una correzione servono tre o quattro settimane perché il report cambi colore. Annota i valori sul campo prima di intervenire, applica una modifica per volta e ricontrolla a un mese.
Se guardi un report pieno di rosso e non sai da dove partire, la parte difficile non è tecnica: è capire quali pagine contano per il tuo fatturato e quali interventi valgono la spesa. In Holistika lavoriamo con professionisti e PMI proprio su questo, partendo dai dati sul campo del tuo sito. Se vuoi un parere su cosa sistemare per primo, scrivici pure. Il quadro strategico resta quello della nostra guida su come fare SEO.
FAQ
Cosa sono i Core Web Vitals?
Sono tre metriche con cui Google misura l’esperienza reale di chi visita una pagina, raccolte dai browser degli utenti e non da un test simulato. Largest Contentful Paint (LCP) indica quanto ci mette a comparire il contenuto principale della prima schermata. Interaction to Next Paint (INP) misura quanto passa tra un clic e la risposta visibile. Cumulative Layout Shift (CLS) quantifica quanto i contenuti si spostano da soli mentre leggi.
Quali sono le soglie ufficiali da rispettare?
Secondo web.dev, l’LCP è buono a 2,5 secondi o meno, da migliorare tra 2,5 e 4 secondi, scarso oltre 4 secondi. L’INP è buono a 200 millisecondi o meno, da migliorare tra 200 e 500 millisecondi, scarso oltre 500 millisecondi. Il CLS è buono a 0,1 o meno, da migliorare tra 0,1 e 0,25, scarso oltre 0,25. Si valutano tutte sul 75esimo percentile delle visite reali, distinguendo mobile e desktop.
Perché PageSpeed Insights e Search Console danno risultati diversi?
Perché usano fonti diverse. Il punteggio da 0 a 100 di PageSpeed Insights nasce da un test di laboratorio, cioè un caricamento simulato su un dispositivo di fascia media. Search Console usa invece i dati sul campo del Chrome UX Report, raccolti da utenti reali su 28 giorni e riportati al 75esimo percentile. Sono questi a determinare la valutazione. Un punteggio di laboratorio basso con dati sul campo verdi non è un’emergenza; il contrario sì.
I Core Web Vitals influiscono davvero sul posizionamento?
Sì, ma meno di quanto si racconti. Google afferma che i Core Web Vitals sono usati dai suoi sistemi di ranking e, nella stessa pagina, che non esiste un segnale unico di esperienza di pagina e che buoni risultati nei report non garantiscono di posizionarsi in alto. La rilevanza viene prima: una pagina che risponde meglio alla domanda dell’utente vince anche se è più lenta. Il ritorno più concreto riguarda le conversioni.
Quanto tempo serve per vedere i miglioramenti nel report?
Da tre a quattro settimane dopo la correzione, anche quando l’intervento tecnico ha effetto immediato. Il motivo è che la valutazione si basa su 28 giorni di dati reali: finché quella finestra contiene giornate precedenti alla correzione, i valori restano mescolati. Search Console applica lo stesso periodo quando chiedi la convalida. Il metodo che funziona è annotare i valori prima di intervenire, applicare una modifica per volta e ricontrollare dopo un mese.