Core Web Vitals Spiegati Bene (Senza le Solite Semplificazioni)

La maggior parte degli articoli sui Core Web Vitals si ferma a “il tuo sito deve essere veloce”. Vero, ma inutile senza numeri precisi e senza capire cosa viene effettivamente misurato. Ecco la versione seria.

In sintesi
Le tre metriche Core Web Vitals hanno soglie precise: LCP sotto 2,5 secondi, INP sotto 200 millisecondi, CLS sotto 0,1. Vanno misurate con dati di campo reali (Google Search Console, sezione Esperienza) e non solo con punteggi di laboratorio come Lighthouse, che possono risultare perfetti anche quando l’esperienza reale degli utenti non lo è.

Le tre metriche, con soglie precise

• LCP (Largest Contentful Paint): misura quanto tempo impiega a caricarsi il contenuto più grande visibile nello schermo (spesso un’immagine hero o un blocco di testo principale). Soglia “Buono”: sotto i 2,5 secondi. Sopra i 4 secondi è considerato scarso.
• INP (Interaction to Next Paint): ha sostituito il vecchio FID nel 2024 e misura la reattività del sito a ogni interazione dell’utente (click, tap, digitazione) durante l’intera visita, non solo alla prima interazione. Soglia “Buono”: sotto i 200 millisecondi.
• CLS (Cumulative Layout Shift): misura quanto gli elementi della pagina si spostano inaspettatamente durante il caricamento (es. un banner pubblicitario che spinge in basso il testo che stavi per leggere). Soglia “Buono”: sotto 0,1.

Perché “il sito sembra veloce” non significa nulla

La percezione soggettiva di velocità, aperta sul tuo computer con connessione fibra e cache già calda, non ha alcuna relazione con l’esperienza reale di un utente su una connessione mobile 4G, con un dispositivo di fascia media, che visita il sito per la prima volta. I Core Web Vitals vanno misurati con dati reali, non con impressioni.

Le cause reali, non i sintomi

• Immagini non ottimizzate: la causa numero uno di LCP scarso. Formati moderni (WebP, AVIF), dimensionamento corretto e lazy loading fanno la differenza più grande in assoluto.
• JavaScript non necessario o non differito: script di terze parti (chat, tracking, widget) caricati in modo bloccante rovinano sia LCP che INP. Ogni script va valutato: serve davvero, e può essere caricato dopo il contenuto principale?
• Font non ottimizzati: font esterni caricati senza font-display corretto causano sia ritardi che, se mal gestiti, shift del layout.
• Hosting inadeguato: nessuna ottimizzazione frontend compensa un server lento a rispondere. Il Time to First Byte è la base su cui si costruisce tutto il resto.
• Elementi senza dimensioni riservate: immagini, banner o iframe senza altezza/larghezza definite nel codice causano CLS quando si caricano e spostano il contenuto già visibile.

Come si misurano correttamente

Esistono due tipi di dati, spesso confusi:

• Dati di laboratorio (lab data): generati da strumenti come Lighthouse o PageSpeed Insights in condizioni controllate e simulate. Utili per il debug, ma non riflettono l’esperienza reale degli utenti.
• Dati di campo (field data / CrUX): raccolti realmente dai browser Chrome degli utenti che visitano il tuo sito, visibili in Google Search Console nella sezione “Esperienza”. Sono questi i dati che Google usa effettivamente come fattore di ranking.

Un sito può avere un punteggio Lighthouse perfetto in laboratorio e comunque avere Core Web Vitals scarsi nei dati di campo reali, se il traffico reale arriva prevalentemente da connessioni lente o dispositivi meno performanti.

Strumenti gratuiti per monitorarli

Non serve un abbonamento a strumenti professionali per iniziare a monitorare i Core Web Vitals del tuo sito. PageSpeed Insights (pagespeed.web.dev) mostra sia dati di laboratorio che, se il sito ha traffico sufficiente, dati di campo reali. Google Search Console, nella sezione “Esperienza → Core Web Vitals”, mostra l’andamento nel tempo diviso per mobile e desktop, con le pagine specifiche che hanno problemi. Chrome DevTools (pannello Lighthouse e Performance) permette un debug dettagliato elemento per elemento. web.dev/measure offre un’analisi guidata pensata anche per chi non è sviluppatore. Il monitoraggio va fatto con continuità, non una tantum: un aggiornamento del tema, un nuovo plugin o una nuova immagine caricata male possono far precipitare le metriche da un giorno all’altro.

Quanto contano davvero per la SEO

I Core Web Vitals sono un fattore di ranking, confermato ufficialmente da Google, ma non l’unico e non il più pesante: la pertinenza e la qualità dei contenuti restano prioritari. Il loro impatto reale è più evidente in mercati competitivi, dove a parità di qualità dei contenuti tra competitor, la performance tecnica fa la differenza tra prima e seconda pagina.

Il nostro approccio

Ogni sito che sviluppiamo parte da un’architettura tecnica pensata per le performance: immagini ottimizzate di default, JavaScript minimo e differito, hosting adeguato al progetto. Non ottimizziamo i Core Web Vitals a posteriori con toppe: li progettiamo bene dall’inizio.

Domande frequenti

Un punteggio PageSpeed di 100/100 garantisce Core Web Vitals perfetti?
No. Il punteggio 0-100 di PageSpeed è un indicatore sintetico di laboratorio: un sito può avere un punteggio alto e comunque avere problemi nei dati di campo reali raccolti dagli utenti veri, specialmente su connessioni lente.

Quanto tempo serve perché un miglioramento tecnico si veda nei dati di Search Console?
I dati di campo di Search Console si basano su una media mobile di 28 giorni: un miglioramento reale richiede circa un mese prima di riflettersi completamente nei report.

I Core Web Vitals contano allo stesso modo per tutti i settori?
L’importanza relativa varia: per e-commerce e siti con alta competizione locale l’impatto su conversioni e ranking è più marcato; per siti con contenuti molto specifici e poca concorrenza diretta, la qualità dei contenuti pesa proporzionalmente di più.

Vuoi sapere i veri Core Web Vitals del tuo sito, con dati reali e non solo un punteggio di laboratorio? Richiedi un audit tecnico gratuito.