SEO & GEO
Core Web Vitals spiegati semplice: cosa sono e perché Google ti penalizza
Core Web Vitals 2026 spiegati a chi non è sviluppatore: LCP, INP, CLS. Soglie reali, come misurarli, cosa migliora ognuno.
Stefano Prandi — 2026-06-04
Hai aperto PageSpeed Insights, hai visto numeri rossi e sigle incomprensibili: LCP, INP, CLS. Magari Search Console ti ha mandato un'email dicendo che le tue pagine hanno problemi di esperienza utente. Eppure il sito ti sembra funzionare.
Benvenuto nel mondo dei Core Web Vitals, il sistema con cui Google misura quanto è davvero veloce il tuo sito per gli utenti reali. Non per un robot in laboratorio, ma per le persone in carne e ossa che lo aprono dal divano con il Wi-Fi ballerino o in metro con il 4G a singhiozzo.
In questo articolo te li spiego come li spiegherei a mio cognato: niente gergo, solo metafore concrete, soglie precise e cosa fare se sei messo male.
Come Google misura davvero la velocità: il segreto si chiama CrUX
Prima di tutto chiariamo un equivoco. Google non stima la velocità del tuo sito con un test sintetico una volta a settimana. La misura in continuo sui veri utenti Chrome che visitano la tua pagina, raccogliendo i dati nel Chrome User Experience Report (CrUX).
Quando vai su PageSpeed Insights vedi due blocchi:
- Lab data: una simulazione fatta lì sul momento. Utile in fase di sviluppo
- Field data: i numeri reali degli ultimi 28 giorni dai veri utenti
Il ranking Google guarda i field data. Per questo può capitare che PageSpeed Insights ti dica "tutto verde" in laboratorio ma Search Console ti segnali pagine lente: la simulazione è fatta da un server vicino con linea perfetta, gli utenti reali aprono il tuo sito da uno smartphone di tre anni fa.
Detto questo, tre metriche fanno la differenza. Vediamole.
LCP – Largest Contentful Paint (≤ 2.5 secondi)
Cosa misura: quanto tempo passa dall'inizio del caricamento al momento in cui appare l'elemento più grande visibile sopra la piega. Di solito è l'immagine hero o il titolone H1.
Metafora: immagina di entrare in un ristorante. L'LCP è il momento in cui ti portano il piatto principale, non l'antipasto. Se aspetti più di 2.5 secondi cominci a pensare che ti abbiano dimenticato.
Cause comuni di LCP alto
- Immagine hero pesante: 3 MB di JPG quando ne bastavano 80 KB in WebP
- Server lento a rispondere (TTFB > 600 ms): hosting condiviso che ansima
- Font bloccanti: 4 famiglie Google Fonts caricate prima di mostrare nulla
- Render-blocking JavaScript: librerie enormi che bloccano il primo paint
4 fix concreti
- Comprimi le immagini in WebP o AVIF e servile con
srcset responsive. Da 3 MB a 80 KB con qualità identica all'occhio
- Aggiungi
- Sposta su CDN o passa a un hosting con TTFB < 200 ms
- Inlinea il CSS critico e fai lazy load di tutto il resto sotto la piega
INP – Interaction to Next Paint (≤ 200 millisecondi)
Cosa misura: la latenza tra quando clicchi, tocchi o digiti qualcosa e quando lo schermo risponde visivamente. Lo misura per tutte le interazioni della sessione, non solo la prima.
INP è subentrato a FID (First Input Delay) il 12 marzo 2024 come metrica ufficiale Core Web Vitals. Motivo: FID misurava solo il primo click, dando un quadro distorto. Tu cliccavi su Accept Cookie e quella era la vita di tutta la pagina. INP invece tiene d'occhio l'intera visita: form, menu hamburger, slider, filtri prodotto. Più realistico.
Metafora: stai parlando con qualcuno. FID era "quanto tempo ci mette a rispondere alla prima domanda?". INP è "in tutta la conversazione, qual è la pausa più lunga che ti fa?".
Come migliorare INP
- Debounce / throttle su input ad alta frequenza (filtri, ricerca live)
- Code splitting: spezza i bundle JS, carica solo quello che serve alla pagina corrente
- Web Workers per calcoli pesanti, così non blocchi il main thread
- Riduci le librerie di terze parti: chat widget, heatmap, A/B test sommano latenza
- Tagga long task (> 50 ms) in DevTools e ottimizza i tre peggiori
Una regola pratica: se hai più di 300 KB di JavaScript compresso, INP soffrirà. Vedo siti WordPress con 1.4 MB di JS bloccante e poi ci si chiede perché Google non li ama.
CLS – Cumulative Layout Shift (≤ 0.1)
Cosa misura: di quanto si "muovono" gli elementi della pagina mentre carica. Quel fastidio quando stai per cliccare un link e ti spunta un banner che ti fa cliccare qualcos'altro? Quello.
Metafora: hai messo a tavola le posate e qualcuno te le sposta mentre stai per prendere la forchetta. Una volta passa, dieci volte diventi nervoso. CLS misura quante volte ti spostano la forchetta.
Come fixare CLS
- Specifica
width e height su tutte le immagini e i video. Il browser così riserva lo spazio prima ancora di caricarli
- Usa
font-display: optional o swap con size-adjust per evitare il salto FOUT/FOIT quando il font custom rimpiazza quello di sistema
- Niente iniezione DOM tardiva sopra il contenuto: banner cookie, ad, notifiche → riservagli spazio fisso o falli partire dal basso
- Animazioni con
transform, mai con proprietà che cambiano il layout (top, left, width, height)
- Reserve space per embed esterni (YouTube, mappe, social): metti un contenitore con
aspect-ratio definito
Gli strumenti per misurare
| Strumento | Tipo dati | Quando usarlo | |---|---|---| | PageSpeed Insights | Lab + Field | Test rapido di una singola URL | | Search Console → Esperienza Pagina | Field (CrUX) | Vedere il quadro su tutto il sito, raggruppato per problema | | Chrome DevTools → Performance | Lab dettagliato | Trovare il bottleneck preciso, profile flame chart | | Lighthouse (in DevTools) | Lab | Audit completo + suggerimenti automatici | | Web Vitals Extension | Field live | Vedere i tuoi numeri mentre navighi il sito reale |
Lab vs Field: perché GSC dice no e PSI dice sì
Capita spesso. Tu lanci PageSpeed Insights, vedi 95/100, esulti. Poi apri Search Console e ti dice "12 pagine con problemi di Esperienza". Cos'è successo?
- PSI lab simula da un server in Europa con fibra perfetta su un Moto G di riferimento
- Field data sono i tuoi utenti veri: che magari sono per il 70% mobile, su 4G mediocre, con uno smartphone di fascia bassa
Il dato che conta per il ranking è quello field. Se Search Console dice male, è male, indipendentemente dal punteggio Lighthouse.
Le soglie ufficiali 2026
Stampatele e attaccale al muro:
| Metrica | Good | Needs Improvement | Poor | |---|---|---|---| | LCP | ≤ 2.5 s | 2.5 – 4.0 s | > 4.0 s | | INP | ≤ 200 ms | 200 – 500 ms | > 500 ms | | CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
Per essere classificato Good su una metrica, il 75esimo percentile dei tuoi utenti deve stare sotto la soglia. Tradotto: se 3 utenti su 4 sono ok, sei ok. Se 1 su 3 è lento, sei nel Needs Improvement.
Quanto pesano davvero sul ranking?
Domanda da un milione di euro. Risposta onesta: pochi punti, ma decisivi su query competitive.
Google lo dice chiaramente: i Core Web Vitals sono uno dei tanti segnali di ranking. Non ti faranno mai battere un competitor che ha contenuti dieci volte più rilevanti. Ma quando 10 risultati sono tutti pertinenti per la stessa query, la velocità diventa il tie-breaker che decide chi va in posizione 3 e chi in posizione 7.
Ricordati anche che la velocità ha effetti indiretti enormi: ogni secondo di LCP in più tende a far perdere circa il 7% di conversioni e ad alzare la frequenza di rimbalzo. Anche se Google non ti penalizzasse, ti penalizzano i tuoi utenti.
Se vuoi un quadro più ampio dell'impatto SEO/GEO nel 2026, ti rimando a come posizionarsi su Google nel 2026 per PMI.
Case study: AImpact, 100/100 PageSpeed
Quando ho costruito AImpact — archivio tecnico dell'evoluzione AI dal 2020 in poi — l'obiettivo era ottenere il punteggio perfetto su PageSpeed Insights. Risultato: 100/100 su tutte e quattro le categorie, in mobile e desktop. Come?
- Astro statico: zero JavaScript di default, solo HTML servito da CDN
- Immagini ottimizzate in WebP con
srcset e dimensioni esplicite (CLS = 0)
- Font self-hosted con preload e
font-display: swap
- Hydration selettiva: JS solo dove serve davvero (toggle livello lettura)
- Zero librerie pesanti: no jQuery, no framework UI runtime, no analytics bloccanti
Stesso approccio su StepDesign: 95+ PageSpeed, LCP sotto 1.2 secondi. Non è magia, è il risultato di scelte architetturali precise. Se ti interessa il confronto con WordPress, qui spiego perché un sito statico è 5x più veloce.
In pratica: da dove parto?
Se hai letto fin qui e ti stai chiedendo "ok, ma per il mio sito?", ecco l'ordine giusto:
- Apri Search Console → Esperienza Pagina. Guarda il quadro field reale
- Lancia PageSpeed Insights sulla home e sulla pagina più trafficata
- Identifica la peggiore delle tre metriche e lavora prima su quella
- Misura di nuovo dopo 28 giorni: i field data ci mettono un mese a rifletterti gli interventi
Non cercare di portare tutto a 100 al primo colpo. Porta tutto in zona Good e basta: Google non premia chi fa 100, premia chi sta sopra la soglia.
Se i tuoi Core Web Vitals sono rossi e non sai da dove cominciare, posso analizzare il tuo sito e darti una roadmap concreta: cosa sistemare per primo, costo stimato, ROI in termini SEO e di conversioni. Mi trovi su stepdesign.prandi.net.
Per chi vuole scendere ancora più in profondità, ti consiglio la documentazione ufficiale di Google su web.dev/vitals e il tool live pagespeed.web.dev per testare le singole pagine.
FAQ
Cosa sono i Core Web Vitals?
Sono tre metriche di velocità ed esperienza utente che Google misura sui veri visitatori del tuo sito tramite Chrome. Definiscono se una pagina è veloce, reattiva e visivamente stabile.
Quali sono i valori soglia 2026 per LCP, INP, CLS?
LCP ≤ 2.5 secondi, INP ≤ 200 millisecondi, CLS ≤ 0.1. Sotto queste soglie la pagina è considerata Good. Sopra entri in Needs Improvement o Poor.
I Core Web Vitals influenzano il ranking Google?
Sì, ma con peso moderato: contano come tie-breaker e diventano decisivi su query competitive dove tutti i risultati sono pertinenti. Il peso cresce sulle ricerche da mobile.
Come miglioro LCP del mio sito?
Tre azioni: comprimi e converti in WebP o AVIF l'immagine hero, attiva preload su font e immagine principale, riduci il tempo di risposta del server sotto i 600 ms.
Cosa è INP e perché ha sostituito FID?
INP misura la latenza di tutte le interazioni utente durante la visita, non solo la prima come faceva FID. Da marzo 2024 è metrica ufficiale Core Web Vitals perché riflette meglio l'esperienza reale.
Richiedi un preventivo