I Core Web Vitals sono tre metriche con cui Google misura l’esperienza reale di chi visita il tuo sito. La prima dice quanto velocemente compare il contenuto principale (LCP), la seconda quanto rapidamente la pagina risponde a un clic o a un tocco (INP) e la terza quanto resta ferma mentre carica (CLS). Se hai una piccola impresa, uno studio professionale o una startup, contano per due motivi. Fanno parte dei segnali che Google considera nel posizionamento, e soprattutto stabiliscono se un potenziale cliente resta sulla pagina o torna ai risultati di ricerca. Qui trovi le soglie da raggiungere, gli strumenti gratuiti per misurarle e le correzioni che di solito spostano davvero i numeri.
In breve
- Le metriche sono tre: LCP (caricamento) va tenuto entro 2,5 secondi, INP (reattività) entro 200 millisecondi e CLS (stabilità visiva) entro 0,1.
- L’INP ha preso il posto del FID il 12 marzo 2024. Se una guida ti parla ancora di FID, è superata.
- Contano i dati degli utenti reali: Google valuta il 75° percentile delle visite, su mobile e su desktop.
- Un 100/100 in Lighthouse non è l’obiettivo: se i tuoi visitatori reali hanno un’esperienza buona, il sito è a posto.
- Nel ranking pesano, ma non decidono da soli: un contenuto utile resta il fattore principale, e un sito veloce lo rende più efficace.
Indice
- Le tre metriche, spiegate senza gergo
- Perché i Core Web Vitals contano per un’azienda
- Come misurare la velocità del tuo sito
- Come migliorare l’LCP
- Come migliorare l’INP
- Come migliorare il CLS
- Gli errori che costano tempo e denaro
- Il nostro punto di vista
- Quando conviene farsi aiutare
- Domande frequenti
- Fonti
Le tre metriche, spiegate senza gergo
Secondo la documentazione di Google Search Central, i Core Web Vitals misurano l’esperienza reale degli utenti in tre aspetti: prestazioni di caricamento, interattività e stabilità visiva. Ogni metrica ha una soglia “Buono” e una soglia oltre la quale l’esperienza è considerata “Scadente”. In mezzo c’è la fascia “Da migliorare”.
| Metrica | Cosa misura | Buono | Da migliorare | Scadente |
|---|---|---|---|---|
| LCP, Largest Contentful Paint | Tempo di comparsa del contenuto principale | fino a 2,5 s | da 2,5 a 4 s | oltre 4 s |
| INP, Interaction to Next Paint | Tempo di risposta a clic, tocchi e tasti | fino a 200 ms | da 200 a 500 ms | oltre 500 ms |
| CLS, Cumulative Layout Shift | Quanto si spostano gli elementi durante la visita | fino a 0,1 | da 0,1 a 0,25 | oltre 0,25 |
C’è un dettaglio che molti trascurano. Per superare la prova non basta che la media sia buona: Google chiede che la soglia “Buono” venga raggiunta al 75° percentile delle visite. In pratica tre visitatori su quattro devono avere un’esperienza buona, e il calcolo vale separatamente per mobile e per desktop. Il ragionamento dietro questa scelta è spiegato nell’articolo di web.dev su come sono state definite le soglie.
LCP: quanto ci mette a comparire ciò che conta
L’LCP misura il momento in cui compare l’elemento più grande visibile senza scorrere. Di solito è l’immagine di copertina, un video in apertura o un grande blocco di testo. Per il visitatore coincide con la sensazione che la pagina sia arrivata. Prendi un ristorante: se la foto del piatto e il pulsante “Prenota” compaiono dopo cinque secondi su uno smartphone con il 4G, molti clienti saranno già passati al risultato successivo.
INP: quanto risponde la pagina quando la usi
L’INP osserva le interazioni durante tutta la visita, come il tocco su un menu, l’invio di un modulo o l’apertura di un filtro, e registra quanto tempo passa prima che lo schermo mostri una reazione. Google ha annunciato nel 2023 l’arrivo dell’INP come metrica più completa del vecchio FID, che considerava solo la prima interazione. Un INP alto si riconosce subito: tocchi un pulsante e per un attimo non succede nulla.
CLS: quanto “balla” la pagina
Il CLS misura gli spostamenti imprevisti del layout. È il classico caso in cui stai per toccare “Chiama” e all’improvviso si carica un banner sopra, il testo scende e finisci su un altro link. Non è solo un fastidio, perché porta a clic sbagliati e fa perdere fiducia.
Perché i Core Web Vitals contano per un’azienda
Google spiega che i Core Web Vitals rientrano nei segnali di page experience usati dai suoi sistemi di ranking. La stessa pagina dice però due cose che vale la pena tenere presenti. La prima: un buon punteggio nei report non garantisce il primo posto, perché la pertinenza e la qualità del contenuto restano più importanti. La seconda: chi vuole risultati non dovrebbe concentrarsi su uno o due aspetti dell’esperienza, ma sull’insieme.
Il motivo per cui Google ha introdotto questi segnali è scritto nell’annuncio sulla page experience del 2020: studi interni e ricerche di settore mostrano che gli utenti preferiscono i siti che offrono una buona esperienza di pagina. Per un’attività locale vuol dire una cosa molto concreta. Chi cerca “idraulico Palermo” o “dentista vicino a me” dal telefono apre due o tre risultati e sceglie quello che funziona meglio.
Ancora più utile è il modo in cui MDN descrive la performance web: la velocità è soprattutto una percezione. Conta quanto presto la pagina mostra qualcosa, quanto presto si può usare e quanto è fluida mentre la usi. Un sito tecnicamente “caricato” che però sembra bloccato viene giudicato lento.
Come misurare la velocità del tuo sito
Dati di laboratorio e dati sul campo
Prima di aprire qualsiasi strumento serve una distinzione, quella tra i due tipi di dati spiegata da web.dev in perché i dati di laboratorio e sul campo sono diversi.
- Dati di laboratorio: un test simulato su un dispositivo e una rete predefiniti, come fa Lighthouse. Servono per trovare i colli di bottiglia e per controllare una modifica prima di pubblicarla.
- Dati sul campo: le misurazioni raccolte dagli utenti reali di Chrome nel Chrome User Experience Report (CrUX), calcolate sugli ultimi 28 giorni. Sono questi i dati che Google usa per valutare i Core Web Vitals.
I due numeri non coincidono quasi mai, e va bene così. Il laboratorio non conosce il telefono e la connessione dei tuoi clienti veri. Ci sono poi due limiti da conoscere, descritti nella guida web.dev per iniziare a misurare i Web Vitals. L’INP non si può misurare in laboratorio, perché richiede interazioni reali, e lo si stima con il Total Blocking Time (TBT). Il CLS di laboratorio tende a sembrare migliore del reale, perché il test non scorre la pagina e non clicca.
PageSpeed Insights, passo dopo passo
PageSpeed Insights è gratuito e mostra entrambe le viste. Ecco come leggerlo senza perdersi:
- Inserisci l’indirizzo della pagina che ti interessa di più, come la home o la pagina del servizio principale, e avvia l’analisi.
- Guarda prima la scheda Dispositivi mobili. Quasi sempre è la più critica.
- Leggi il riquadro in alto, quello con l’esito della valutazione Core Web Vitals: sono i dati sul campo. Se compare “Superata”, i tuoi utenti reali stanno bene.
- Se i dati sul campo mancano, il sito ha troppo poco traffico per il CrUX. In quel caso usa i dati di laboratorio come indicazione di massima.
- Scorri fino alla diagnostica di Lighthouse e annota i tre suggerimenti con il risparmio stimato più alto. Partirai da lì.
Il report in Search Console
PageSpeed analizza una pagina alla volta, mentre il report Core Web Vitals di Search Console guarda l’intero sito. Raggruppa gli URL simili per stato (Buono, Da migliorare, Scadente) e conserva lo storico, così vedi se una modifica ha funzionato. Google consiglia proprio di usare questo report per monitorare il sito e capire dove intervenire. Se il tuo sito non è ancora collegato a Search Console, conviene farlo insieme ai passaggi della nostra guida sull’indicizzazione su Google.
Come migliorare l’LCP
Sui siti di piccole aziende l’LCP lento ha quasi sempre le stesse cause. In ordine di impatto:
- Immagine di copertina troppo pesante. Una foto da 4 MB caricata così come esce dalla fotocamera è la causa più frequente. Ridimensionala alla larghezza reale di visualizzazione, usa formati moderni come WebP o AVIF e non applicare il caricamento differito (lazy loading) all’immagine principale, perché quell’immagine deve arrivare per prima.
- Server lento a rispondere. Se il server impiega molto a inviare il primo byte, ogni altra ottimizzazione parte in ritardo. Un hosting condiviso sovraffollato, la cache assente o un database mai ottimizzato pesano parecchio. Per le aziende che gestiscono un’infrastruttura propria, una gestione dei server per PMI pianificata con criterio è la base su cui poggia anche la velocità del sito.
- CSS e font che bloccano il rendering. Fogli di stile enormi e font caricati da più fonti rallentano la prima visualizzazione. Bastano meno famiglie di caratteri e solo i pesi che usi davvero.
- Slider in apertura. Un carosello da cinque immagini in testa alla home pesa sull’LCP e raramente viene guardato oltre la prima slide. Una sola immagine forte con un messaggio chiaro funziona meglio.
Come migliorare l’INP
L’INP peggiora quando il browser è impegnato a eseguire JavaScript e non riesce a rispondere all’utente. I colpevoli tipici:
- Troppi script di terze parti. Chat, pixel pubblicitari, widget delle recensioni, mappe e banner dei cookie si sommano. Fai l’inventario e chiediti per ciascuno se porta clienti. Quelli che non servono vanno tolti, gli altri caricati dopo l’interazione o in differita.
- Plugin e page builder appesantiti. Su WordPress capita spesso di trovare decine di plugin attivi, molti dei quali caricano codice su ogni pagina anche quando servono solo in una.
- Moduli di contatto lenti o ridondanti. Il modulo è il punto in cui il visitatore diventa un contatto, quindi deve rispondere subito. Un form per il sito collegato al CRM evita di accumulare script e passaggi intermedi e porta la richiesta direttamente dove la gestisci.
- Menu complessi. I mega-menu animati con molti livelli possono bloccare il thread principale al primo tocco. Per progettarne uno leggero e chiaro puoi leggere la nostra guida al menu di navigazione.
Durante lo sviluppo tieni d’occhio il TBT in Lighthouse: se scende, di solito migliora anche l’INP misurato sul campo.
Come migliorare il CLS
Il CLS si corregge quasi sempre con interventi semplici:
- Dichiara le dimensioni di immagini, video e iframe, con gli attributi width e height oppure un rapporto d’aspetto nel CSS. Così il browser riserva lo spazio prima che il contenuto arrivi.
- Riserva lo spazio per banner e annunci. Il banner dei cookie o la barra delle promozioni non devono spingere giù il contenuto dopo il caricamento. Meglio una sovrapposizione in basso o uno spazio già previsto.
- Gestisci i font web, per evitare che il passaggio dal carattere di sistema a quello personalizzato faccia saltare le righe.
- Non inserire contenuti sopra quelli già visibili, a meno che non sia l’utente a chiederlo con un clic.
Ricorda che il laboratorio sottovaluta il CLS. Se Lighthouse dice che va tutto bene ma Search Console segnala problemi, fidati di Search Console e prova la pagina dal telefono, scorrendo e toccando come farebbe un cliente.
Gli errori che costano tempo e denaro
Inseguire il 100/100. Lighthouse simula un dispositivo di fascia media su una rete lenta, e il punteggio cambia da un test all’altro. Come spiega web.dev nella guida al debug delle prestazioni sul campo, sono i dati degli utenti reali a dire se il sito funziona. Passare giorni a limare millisecondi su un punteggio sintetico, quando i dati sul campo sono già buoni, toglie budget a interventi più utili.
Sacrificare il design per un numero. Togliere tutte le foto o il video aziendale per guadagnare due punti è un cattivo affare se proprio quelle immagini convincono il cliente. La strada giusta è lo stesso video ben compresso e caricato al momento giusto.
Ottimizzare solo la home. I clienti spesso arrivano da Google su una pagina servizio o su un articolo del blog. Controlla in Search Console i gruppi di URL con lo stato peggiore.
Pensare alla velocità a sito finito. Quando i problemi dipendono da un tema pesante o da un page builder, a volte la soluzione più economica è ripartire su basi solide. Nella guida al restyling del sito web spieghiamo quando conviene e come farlo senza perdere posizionamento.
Dimenticare il resto della SEO. Un sito velocissimo con titoli generici e contenuti deboli resta invisibile. I Core Web Vitals sono un pezzo della SEO on page, non la sostituiscono.
Il nostro punto di vista
Quando un’azienda ci chiede di “sistemare la velocità”, la prima cosa che facciamo è guardare i dati reali dei suoi utenti, non il punteggio di laboratorio. Capita spesso che un sito con 60 in Lighthouse superi la valutazione sul campo, e che uno con 90 abbia problemi di CLS su mobile che nessun test aveva mostrato. Per noi la performance non è una rifinitura da aggiungere a fine progetto. È una scelta di progettazione: quante immagini mettere in apertura, quali script servono davvero, quale piattaforma usare.
Per questo evitiamo i pacchetti preconfezionati di “ottimizzazione”. Partiamo dai dati, scegliamo i due o tre interventi che pesano di più sulle conversioni del cliente e misuriamo il prima e il dopo. Un sito bello che carica lento perde clienti, ma lo stesso vale per un sito velocissimo che non convince nessuno. Il nostro lavoro è tenere insieme le due cose.
— Teodoro
Quando conviene farsi aiutare
Se PageSpeed segnala problemi che non sai interpretare, o se il tuo sito è costruito su un tema che non puoi alleggerire, ha senso affidarsi a chi progetta siti pensati per la velocità fin dall’inizio. Con il nostro servizio di creazione siti web, a partire da 349 € una tantum, realizziamo siti responsive e ottimizzati, curando sia l’aspetto creativo sia le prestazioni. Se il sito esiste già e vuoi migliorarne posizionamento e risultati, trovi l’ottimizzazione SEO e gli altri servizi nella pagina dei servizi di DigitApp Italia.
Domande frequenti
Cosa sono i Core Web Vitals, in una frase?
Sono tre metriche di Google, LCP, INP e CLS, che misurano quanto velocemente compare il contenuto principale, quanto rapidamente la pagina risponde e quanto resta stabile durante la visita. Si basano sui dati di utenti reali raccolti da Chrome.
Come posso misurare la velocità del mio sito gratis?
Usa PageSpeed Insights per analizzare le singole pagine e il report Core Web Vitals di Search Console per avere una visione dell’intero sito nel tempo. Parti sempre dalla versione mobile e dai dati sul campo.
Perché PageSpeed non mostra i dati sul campo del mio sito?
Succede quando il sito non ha abbastanza visite da utenti Chrome per comparire nel Chrome User Experience Report. In quel caso usa i dati di laboratorio come guida e ricontrolla quando il traffico cresce.
Se miglioro i Core Web Vitals salgo subito su Google?
Non necessariamente. Fanno parte dei segnali di page experience, ma Google precisa che un buon punteggio non garantisce le prime posizioni e che la qualità del contenuto resta il fattore principale. Il beneficio più immediato si vede di solito sui visitatori, che abbandonano meno la pagina.
Il FID esiste ancora?
No, dal 12 marzo 2024 il FID è stato sostituito dall’INP come metrica di reattività dei Core Web Vitals. Se uno strumento o una guida lo cita ancora come metrica principale, le informazioni sono datate.
Fonti
- Google Search Central: Core Web Vitals e risultati di ricerca
- Google Search Central: page experience
- Google Search Central Blog: introduzione dell’INP
- Google Search Central Blog: valutare la page experience
- web.dev: come sono state definite le soglie
- web.dev: dati di laboratorio e dati sul campo
- web.dev: iniziare a misurare i Web Vitals
- web.dev: debug delle prestazioni sul campo
- MDN: performance web
- PageSpeed Insights
Raccomandati
- SEO on page: come ottimizzare le pagine per ottenere risultati nel 2026
- Indicizzazione su Google: come far trovare il tuo sito nel 2026
- Restyling sito web: quando conviene farlo e come affrontarlo senza rischi
- Menu di navigazione: come progettarlo chiaro, accessibile e responsive
