Hai il dominio giusto, l'SSL attivo, i contenuti curati. Poi apri PageSpeed Insights dal telefono, guardi il numero rosso in cima alla pagina e ti chiedi cosa diavolo significhi davvero — e soprattutto se sia colpa tua, del tuo hosting o di quel plugin che sembrava così comodo.

La verità è che quel numero grande e colorato non è il voto che Google usa per posizionarti. È una stima di laboratorio. I dati che contano davvero sono altri, si chiamano Core Web Vitals, arrivano dai browser dei tuoi visitatori reali e raccontano una storia molto meno lusinghiera.

In questa guida vediamo cosa sono LCP, INP e CLS, quali soglie devi rispettare, perché il tuo sito probabilmente ne fallisce esattamente uno, e cosa si fa concretamente per sistemarli. Niente scorciatoie magiche: solo ingegneria fatta bene.

Keyword principali: cosa sono i core web vitals, metriche performance Google, page experience.

I Core Web Vitals sono tre metriche con cui Google misura l'esperienza reale di chi visita una pagina. Non sono un punteggio unico, non sono un voto sintetico, e si muovono in modo indipendente l'una dall'altra.

• LCP (Largest Contentful Paint): quanto ci mette a comparire il contenuto principale. Misura il caricamento.

• INP (Interaction to Next Paint): quanto ci mette la pagina a rispondere quando l'utente tocca qualcosa. Misura la reattività.

• CLS (Cumulative Layout Shift): quanto la pagina "balla" mentre si carica. Misura la stabilità visiva.

Tradotto in linguaggio umano: quanto ci metti a farti vedere, quanto ci metti a rispondere, e quanto stai fermo mentre lo fai.

E qui arriva il primo equivoco da smontare. Il numerone che vedi in cima a PageSpeed Insights è un punteggio Lighthouse: una simulazione fatta su un dispositivo virtuale, in condizioni di rete virtuali, in quel preciso istante. Utile per capire perché qualcosa non va, inutile come verdetto. Google non guarda quello. Google guarda i dati di campo.

Keyword principali: CrUX, dati di campo, 75 percentile core web vitals.

I dati di campo arrivano dal CrUX (Chrome User Experience Report): le misurazioni anonime raccolte dai browser Chrome delle persone che visitano davvero il tuo sito. Su smartphone di fascia media. Con il 4G del centro storico. Con venti schede aperte.

La regola di valutazione è questa: una pagina supera una metrica solo se almeno il 75% delle visite reali rientra nella soglia "buona".

Non è la media. È fondamentale capirlo, perché la media perdona e il 75° percentile no. Se hai quattro visitatori e tre volano, ma il quarto aspetta sei secondi, hai fallito. Google non ti giudica sul cliente fortunato: ti giudica sul quarto cliente più sfortunato.

Altre due cose che cambiano tutto:

1. La finestra è di 28 giorni, scorrevole. Se sistemi il sito oggi, i numeri ufficiali si muovono tra tre o quattro settimane. Non farti prendere dal panico il giorno dopo il deploy.

2. Mobile e desktop sono valutati separatamente. Le soglie sono le stesse, ma superarle da mobile è molto, molto più difficile. Ed è lì che sta il tuo traffico.

Keyword principali: migliorare LCP, sito lento caricamento, ottimizzazione immagini web.

Cosa misura: il tempo che passa dall'inizio del caricamento a quando compare l'elemento più grande visibile nella prima schermata. Di solito è l'immagine hero, un video di sfondo o il titolo principale.

Le soglie:

• Buono: fino a 2,5 secondi

• Da migliorare: tra 2,5 e 4 secondi

• Scarso: oltre 4 secondi

Perché fallisce, quasi sempre:

• Hosting lento. Se il server impiega 800ms solo a rispondere, hai già bruciato un terzo del budget prima ancora di inviare un byte utile.

• Immagini enormi. La foto da 4 MB scaricata dallo smartphone e caricata così com'è è il killer numero uno dei siti aziendali italiani.

• CSS e JavaScript che bloccano il rendering. Il browser trova un foglio di stile in testa alla pagina e si ferma ad aspettarlo.

• Rendering lato client. Se il contenuto esiste solo dopo che il JavaScript ha finito di girare, l'utente guarda uno scheletro bianco.

Come si sistema: hosting serio e CDN, immagini in WebP o AVIF con dimensioni realistiche, preload sull'immagine hero, CSS critico in linea, font caricati con preload e font-display: swap. E, se stai ripensando l'architettura, rendering lato server o generazione statica — è esattamente il motivo per cui lavoriamo con Next.js: il contenuto arriva già pronto, il browser non deve costruirlo.

Keyword principali: cos'è INP, INP ottimizzazione, sito che non risponde ai clic.

Se un articolo che stai leggendo parla ancora di FID (First Input Delay), è vecchio: INP lo ha sostituito ufficialmente a marzo 2024. E il cambio non è cosmetico.

FID misurava solo il ritardo del primo clic. INP misura il ciclo completo di ogni interazione della sessione — clic, tap, pressione di tasti — e riporta un valore vicino alla peggiore. Il ritardo iniziale, il tempo di elaborazione, e il tempo che serve al browser per disegnare il risultato sullo schermo.

Le soglie:

• Buono: fino a 200 millisecondi

• Da migliorare: tra 200 e 500 millisecondi

• Scarso: oltre 500 millisecondi

Duecento millisecondi è la soglia sotto la quale il cervello umano percepisce una risposta come "immediata". Sopra, l'utente inizia a dubitare di aver premuto davvero.

Perché INP è il vero problema del 2026: è la metrica che fa cadere più siti, perché è l'unica che non si risolve comprando un hosting migliore o comprimendo un'immagine. INP è JavaScript. E il JavaScript, sui siti costruiti a strati di plugin, si accumula.

Il colpevole tipico è una catena prevedibile: banner cookie che blocca il thread principale, Tag Manager con dentro sei script di tracciamento, widget di chat caricato subito, slider animato, plugin per i form, plugin per la SEO, plugin per il plugin. Ognuno sembra innocuo. Insieme occupano il thread principale per mezzo secondo ogni volta che tocchi qualcosa.

Come si sistema: spezzare i task lunghi e restituire il controllo al browser, rimandare tutto ciò che non serve al primo rendering, caricare i widget di terze parti solo all'interazione (la chat non deve esistere finché nessuno la apre), ridurre il codice di idratazione, e — soprattutto — eliminare, non aggiungere. È il punto in cui il dibattito tra WordPress e sviluppo su misura smette di essere filosofico e diventa un numero in Search Console.

Keyword principali: cos'è il CLS, layout che si sposta, stabilità visiva sito.

Cosa misura: quanto gli elementi si spostano da soli durante il caricamento, senza che l'utente abbia fatto nulla.

Le soglie:

• Buono: fino a 0,1

• Da migliorare: tra 0,1 e 0,25

• Scarso: oltre 0,25

Hai presente quando stai per sederti e qualcuno sposta la sedia? Ecco: il CLS è quello, ma con il pulsante "Richiedi preventivo". Stai per toccarlo, si carica l'immagine sopra, il pulsante scivola giù, e il tuo dito atterra su "Cookie policy". Un CLS alto non è un dettaglio estetico: è un utente che si è appena innervosito.

Le cause classiche:

• Immagini e iframe senza dimensioni dichiarate. Il browser non sa quanto spazio riservare, quindi non ne riserva.

• Font web che si sostituiscono. Il testo carica con il font di sistema, poi arriva quello vero, tutto si ridisegna.

• Banner e avvisi iniettati in cima alla pagina dopo il primo rendering.

• Contenuti caricati dinamicamente sopra a quelli già visibili.

Come si sistema: width e height (o aspect-ratio) su ogni immagine, video, iframe e riquadro pubblicitario. Spazio riservato in anticipo per tutto ciò che arriva dopo. Font precaricati. E la regola d'oro: non inserire mai niente sopra contenuti già visibili, a meno che non sia l'utente a chiederlo.

Keyword principali: PageSpeed Insights come usarlo, Search Console core web vitals, misurare velocità sito.

Quattro strumenti, ognuno con un ruolo preciso:

• PageSpeed Insights: ti mostra sia i dati di campo (in alto, quelli che contano) sia quelli di laboratorio. Guarda sempre prima la sezione dei dati reali.

• Google Search Console → Segnali web essenziali: la vista d'insieme sull'intero sito, con le URL raggruppate per problema. È qui che capisci se il problema è una pagina o un template.

• Lighthouse e il pannello Performance di Chrome DevTools: laboratorio puro. Servono a capire perché, non se.

• La libreria web-vitals: per raccogliere i dati dei tuoi utenti reali in autonomia, senza aspettare il CrUX.

La regola da ricordare: i dati di campo dicono se stai passando. Quelli di laboratorio dicono perché no. Chi li confonde ottimizza per mesi il numero sbagliato.

Keyword principali: checklist core web vitals, ottimizzare performance sito web.

1. Parti dal campo, non dal laboratorio. Apri Search Console e guarda cosa succede ai tuoi utenti veri, su mobile.

2. Aggredisci prima la fascia rossa. Una metrica "scarsa" fa più danni di due "da migliorare".

3. Trova l'anello debole. La maggior parte dei siti non fallisce su tutto: fallisce su una metrica che trascina giù le altre due. Individuala e concentrati lì.

4. Lavora sui template, non sulle singole pagine. Sistemare il template della scheda prodotto sistema quattrocento URL in un colpo solo.

5. Fai l'inventario delle terze parti. Elenca ogni script esterno e chiediti, per ognuno, cosa succederebbe se lo togliessi. Spesso: niente.

6. Aspetta 28 giorni prima di giudicare. La finestra scorrevole è impietosa con chi ha fretta.

7. Monitora le regressioni. Un plugin aggiornato o una nuova immagine possono rimandare tutto in rosso in una settimana.

Keyword principali: velocità sito e conversioni, performance ecommerce, SEO tecnica.

I Core Web Vitals fanno parte dei segnali di page experience di Google: contano, ma da soli non salvano un contenuto mediocre. Funzionano da discriminante — quando tu e il tuo concorrente avete contenuti simili, la differenza la fa chi carica meglio.

Il punto è che il vero ritorno non è nella SERP. È nel comportamento delle persone. Nella libreria di case study di web.dev c'è un esempio che dovrebbe interessarti in modo particolare: Vodafone Italia ha testato due pagine identiche per aspetto e funzioni, cambiando solo la performance. Un miglioramento dell'LCP del 31% ha prodotto l'8% di vendite in più.

Stesso sito, stessa offerta, stesso traffico. Solo più veloce.

Un form che si impunta all'invio, un'immagine che sposta il pulsante di contatto, una pagina mobile che arranca: sono perdite silenziose, che non compaiono in nessun report perché nessuno ti scrive per dirti "ho lasciato il sito". È il motivo per cui continuiamo a sostenere che la velocità sia una forma di rispetto prima ancora che una tattica SEO.

I Core Web Vitals sono un fattore di ranking? Sì, dal 2021 fanno parte dei segnali di page experience. Non sono il fattore più importante — la pertinenza del contenuto viene prima — ma in settori competitivi diventano l'ago della bilancia.

Ho 100 su PageSpeed ma Search Console dice che sto fallendo. Com'è possibile? Perfettamente normale. Il 100 è un test di laboratorio sul tuo computer. Search Console riporta gli utenti reali su dispositivi reali. Vince sempre il secondo.

Quanto tempo serve per vedere i risultati? Almeno un mese. I dati CrUX si aggiornano su una finestra scorrevole di 28 giorni: le correzioni di oggi entrano gradualmente nel calcolo.

Basta installare un plugin di ottimizzazione? Su LCP e CLS un buon plugin di caching può aiutare. Su INP, quasi mai — perché il problema è la quantità di JavaScript, e un plugin in più è JavaScript in più.

In Studio Faraj costruiamo siti su misura, senza sovrastrutture inutili e senza canoni mensili, progettati per essere veloci dal primo giorno anziché ottimizzati a posteriori.

Se vuoi sapere a che punto sei — e cosa serve davvero per sistemarlo — parliamo del tuo progetto. La prima consulenza è gratuita.

Studio Faraj — Sviluppo web, SEO e performance. Padova, Italia.