«Il sito è un po’ lento, ma alla fine vende lo stesso.»
Forse. Ma non saprai mai quanto vende in meno. Perché chi se ne va dopo tre secondi d’attesa non ti lascia un biglietto con su scritto perché: chiude e basta. E Google, quella lentezza, la misura e la usa contro di te.
I Core Web Vitals sono le metriche con cui Google valuta l’esperienza vera sul tuo sito. Non un tecnicismo per smanettoni: un fattore che tocca insieme le tue conversioni e il tuo posizionamento. Vediamoli in modo chiaro e, soprattutto, vediamo cosa farci.
Le tre metriche che contano, con le soglie vere
Nel 2026 i Core Web Vitals sono tre. Ognuno misura un aspetto diverso dell’esperienza, e Google ha soglie precise per considerarli «buoni».
- LCP (Largest Contentful Paint): la velocità di caricamento. Quanto tempo passa prima che compaia il contenuto principale della pagina. Buono: sotto 2,5 secondi. Oltre i 4 secondi è considerato scarso.
- INP (Interaction to Next Paint): la reattività. Quanto ci mette la pagina a rispondere quando l’utente clicca o tocca qualcosa. Buono: sotto 200 millisecondi. È la metrica che più siti falliscono nel 2026, quindi è spesso lì che c’è di più da guadagnare. Occhio però: si misura sugli utenti reali, non nel test «da laboratorio» di PageSpeed, e tra un attimo ti spiego perché (è la cosa che confonde di più).
- CLS (Cumulative Layout Shift): la stabilità visiva. Quanto «saltano» gli elementi mentre la pagina carica (quel fastidio per cui vai per cliccare una cosa e il dito ti finisce su un’altra). Buono: sotto 0,1.
Velocità, reattività, stabilità. Tre facce della stessa domanda: usare il tuo sito è piacevole o è una sofferenza?
Il dettaglio che ribalta tutto: contano gli utenti veri
Qui casca l’asino di parecchi. Google non guarda come va il sito sul tuo computer con la tua connessione da fibra. Guarda i dati reali degli utenti. E il verdetto è «buono» solo quando almeno il 75% delle visite rispetta le soglie per tutte e tre le metriche.
Tradotto: il fatto che «a te sembra veloce» non conta niente. Il tuo cliente sullo smartphone, con una connessione media, magari in movimento sul treno, vive un sito diverso dal tuo. È la sua esperienza che pesa, non la tua impressione da scrivania.
Perché su PageSpeed non trovi l’INP (e cosa guardare al suo posto)
Qui c’è la trappola che manda in confusione un sacco di gente, e a ragione. Apri PageSpeed Insights, cerchi l’INP tra i risultati del test e… non c’è. Vedi FCP, LCP, TBT, CLS, Speed Index, ma dell’INP con un punteggio nessuna traccia. Non stai sbagliando niente tu: è fatto così di proposito.
Il motivo, quando lo capisci, è semplice. Il test «in laboratorio» di PageSpeed è un robot che carica la pagina e la misura. Ma l’INP misura quanto la pagina risponde quando una persona ci clicca sopra. E un robot che carica e basta non clicca niente: non può misurare una reattività che nasce solo dall’interazione umana. Per questo, in laboratorio, l’INP semplicemente non compare.
Al suo posto il laboratorio ti dà un sostituto: il TBT (Total Blocking Time), cioè quanto il «motore» della pagina resta bloccato durante il caricamento. È un buon indizio, non una fotocopia. Un TBT alto ti dice quasi sempre che l’INP sarà messo male; però può capitare un TBT a zero e un INP comunque scarso, perché il blocco arriva dopo, nel momento in cui l’utente interagisce davvero.
L’INP vero, quindi, lo leggi solo tra i dati di campo, cioè dai tuoi utenti reali: è la sezione in alto di PageSpeed, quella intitolata «Scopri l’esperienza dei tuoi utenti reali». E qui c’è il rovescio della medaglia: se il tuo sito ha poco traffico, Google non ha abbastanza dati reali e quella sezione non appare proprio. Ecco perché su un mucchio di siti piccoli l’INP non si vede e basta. Quella riga «Suddivisione INP» senza il pallino verde che hai trovato è solo un suggerimento diagnostico (ti indica l’interazione più lenta su cui indagare), non un voto.
In pratica, per non impazzire: se non hai i dati di campo, guarda il TBT in laboratorio come spia della reattività, e appoggiati alla Search Console (il rapporto Segnali web essenziali), che raccoglie l’INP reale dei tuoi visitatori quando il traffico basta. E se vuoi provare di persona sul tuo computer, l’estensione Web Vitals di Chrome ti mostra l’INP mentre navighi e clicchi davvero nel sito.
Cosa rende lento un sito, quasi sempre le stesse cose
Nella stragrande maggioranza dei casi, la lentezza nasce da pochi colpevoli che tornano sempre.
- Immagini pesanti, caricate a piena risoluzione quando basterebbe molto meno.
- Troppi script e plugin che si accavallano, tipico dei siti costruiti a strati negli anni, dove nessuno ha mai tolto niente.
- CSS e JavaScript che bloccano il rendering, cioè costringono la pagina ad aspettarli prima di mostrarsi. È spesso la causa principale di INP e LCP scarsi sui siti fatti col page builder.
- Un hosting inadeguato, che risponde lento già alla radice.
Ne avevo parlato dal lato SEO qui: perché un sito lento e con codice sporco perde visibilità. La lentezza non è mai un problema estetico, è strutturale.
Come sistemarli, in ordine di impatto
La buona notizia è che i rimedi sono noti e, in buona parte, alla portata di una PMI senza rifare il sito da zero.
- Ottimizza le immagini. Compressione e formati moderni (WebP/AVIF): spesso è il guadagno più grosso con lo sforzo più piccolo. Uno strumento di ottimizzazione automatica ti fa il lavoro senza pensieri.
- Metti una buona cache e una CDN. Servire le pagine già pronte e da server vicini all’utente abbatte i tempi. Servizi come Nitropack mettono insieme cache, CDN, lazy load e critical CSS pensati proprio per i Core Web Vitals, ed è tra i più solidi su questo fronte.
- Riduci gli script che bloccano. Meno plugin inutili, caricamento differito di quello che non serve subito. È la leva più delicata (può romperti il layout), quindi va fatta testando ogni passaggio. Ed è anche la leva che più sposta l’INP, visto che l’INP si gioca proprio su quanto il motore della pagina resta libero di rispondere.
- Parti da un hosting all’altezza. Dove gira il sito conta quanto quello che ci metti sopra. Un hosting gestito come Cloudways parte con basi migliori in termini di velocità di risposta.
L’errore comune
Rincorrere il punteggio senza guardare i dati veri. Un sacco di gente si fissa sul voto «in laboratorio» di uno strumento di test, lo vede verde sul proprio schermo e si tranquillizza, mentre gli utenti veri su mobile stanno vivendo tutt’altra storia. È esattamente il caso dell’INP: verde o assente in laboratorio, ma magari scarso nella realtà. Oppure attivano dieci ottimizzazioni aggressive tutte insieme, rompono il sito, e a quel punto non sanno più quale ha combinato il guaio.
La regola è la solita: misura sui dati reali (il campo, non il laboratorio), cambia una cosa alla volta, verifica. Le ottimizzazioni di velocità sono utilissime, ma applicate alla cieca su un sito Elementor o simili ti fanno danni estetici seri.
Domande frequenti
I Core Web Vitals influenzano davvero il posizionamento?
Sì, sono un fattore di ranking. Non il più importante da solo, ma a parità di contenuto un sito veloce e stabile parte avvantaggiato, e soprattutto trattiene di più chi arriva.
Perché su PageSpeed non vedo l’INP?
Perché l’INP si misura sugli utenti reali che cliccano, e il test di laboratorio è un robot che carica la pagina senza interagire: non può misurarlo. Lo trovi solo nei dati di campo (in alto in PageSpeed) se hai abbastanza traffico, oppure nella Search Console. In laboratorio, come spia, guarda il TBT.
Qual è la metrica su cui concentrarmi per prima?
Spesso l’INP (la reattività), perché è quella che più siti falliscono, e l’LCP se le immagini sono pesanti. Ma dipende dai tuoi dati veri: prima misura, poi decidi.
Devo rifare il sito?
Quasi mai. Nella maggior parte dei casi si interviene su immagini, cache, script e hosting senza rifare niente. Il rifacimento serve solo quando la base è davvero compromessa.
Basta installare un plugin di velocità?
Aiuta, ma non è una bacchetta magica. Un plugin di ottimizzazione configurato male ti può rompere il layout o addirittura peggiorare le cose. Va impostato con criterio e testato.
Come misuro i dati reali?
Con gli strumenti che leggono l’esperienza degli utenti veri (i dati di campo): la sezione in alto di PageSpeed Insights quando hai abbastanza traffico, e il rapporto Segnali web essenziali di Search Console. Se i dati di campo non ci sono, in laboratorio usa il TBT come spia dell’INP. Sono i dati di campo quelli che Google usa per il suo giudizio.
Se il sito è lento e non sai da dove partire
La velocità di un sito non è un capriccio da tecnici. Sono clienti che restano o se ne vanno, e visibilità che guadagni o perdi. Però va affrontata con metodo, misurando i dati giusti e senza rompere quello che già funziona.
Se vuoi capire quali dei tuoi Core Web Vitals sono davvero in rosso e cosa conviene sistemare per primo, lo guardiamo insieme. Se posso aiutarti te lo dico, se non posso te lo dico lo stesso, così non perdiamo tempo né io né te.
Parliamo della tua situazione: prenota una call conoscitiva senza impegno.
Nota: metriche e soglie verificate a luglio 2026 sulla documentazione Google. I criteri possono evolvere: fai riferimento alle linee guida ufficiali aggiornate.
