Performance

Cosa sono i Core Web Vitals (e cosa misurano davvero)

LCP, INP e CLS misurano caricamento, reattività e stabilità visiva delle visite reali. Ecco le soglie, dove si leggono i dati e cosa le metriche non dicono.

In sintesi

  • LCP, INP e CLS misurano caricamento, reattività e stabilità, non la qualità del contenuto.
  • Le soglie valgono al 75° percentile delle visite reali, separate per mobile e desktop.
  • Senza dati di campo del Chrome UX Report puoi misurare solo in laboratorio: dichiaralo.

I Core Web Vitals sono tre metriche di Google che misurano una pagina reale: LCP per il caricamento, INP per la reattività e CLS per la stabilità visiva. Non misurano la qualità del design né la correttezza del contenuto.

Le tre metriche e le soglie

MetricaCosa misuraBuonoDa correggere
LCPTempo di caricamento dell'elemento più grande visibile≤ 2,5 s> 4 s
INPLatenza tra input e frame successivo≤ 200 ms> 500 ms
CLSSpostamento inatteso del layout≤ 0,1> 0,25

Le soglie si applicano al 75° percentile delle visite, separate per mobile e desktop. Google pubblica i valori su web.dev e li calcola dai dati di campo del Chrome UX Report.

Dove leggere i numeri

I dati di campo arrivano dal Chrome UX Report: utenti reali, ultimi 28 giorni. I dati di laboratorio arrivano da Lighthouse o WebPageTest: una singola esecuzione, con condizioni dichiarate. Servono a cose diverse: il campo decide se la pagina passa, il laboratorio spiega perché.

npx lighthouse https://example.com --only-categories=performance --preset=desktop --output=json --output-path=./lighthouse.json

Il comando richiede Node e una connessione di rete; scrive un report JSON con LCP, CLS e TBT. Lighthouse non misura INP: per la reattività il dato utile è quello di campo, oppure una traccia nel pannello Performance.

Cosa non misurano

Non misurano accessibilità, contenuto o conversione. Non sono nemmeno l'unico segnale di ranking: Google li usa dentro page experience, con peso minore della pertinenza. Una pagina veloce con la risposta sbagliata resta fuori.

La limitazione da dichiarare

Un sito con poco traffico non entra nel Chrome UX Report. In quel caso i Core Web Vitals di campo non esistono e vedi solo il laboratorio: non puoi dichiarare un passaggio che nessun utente ha misurato.

Tre correzioni che spostano i numeri

  • LCP: trova l'elemento più grande con Lighthouse, poi servilo come immagine ottimizzata o come testo. Fonte: web.dev, CC BY 4.0.
  • CLS: assegna larghezza e altezza a ogni immagine e riserva spazio per font e banner.
  • INP: spezza i task lunghi e rimanda il JavaScript non critico.

Dove continuare

Il catalogo EneUI indicizza 111.985 componenti e 1.556 blocchi con preview. Il record image auto slider è il tipo di componente da controllare prima dell'installazione: se le immagini non hanno dimensioni, il CLS sale. Per correggere il layout shift leggi immagini senza dimensioni, per il peso del JavaScript un import che aumenta il bundle, per il confronto misurato tra librerie librerie React 2026.

Domande frequenti

Qual è la differenza tra LCP, INP e CLS?

LCP misura quanto tempo serve per mostrare l'elemento più grande visibile, INP misura la latenza della risposta a un input, CLS misura quanto il layout si sposta senza aspettarselo. Sono tre aspetti diversi della stessa visita.

INP ha sostituito FID?

Sì. INP è diventata una metrica Core Web Vitals il 12 marzo 2024 e ha preso il posto di First Input Delay, che misurava solo il ritardo del primo input.

I Core Web Vitals sono un fattore di ranking?

Sì, tramite page experience, ma con peso minore della pertinenza e della qualità del contenuto. Una pagina lenta può rankare se risponde meglio delle concorrenti; una pagina veloce e vuota no.

Devo guardare i dati di laboratorio o quelli di campo?

Per decidere se una pagina passa guarda i dati di campo del Chrome UX Report. I dati di laboratorio servono a capire quale parte della pagina causa il problema.

Ogni quanto cambiano i valori?

I dati di campo seguono una finestra mobile di 28 giorni, quindi si muovono lentamente. Lighthouse misura una singola esecuzione e cambia a ogni run: non confrontare due run isolati.