Report Core Web Vitals

Dati reali e dati di laboratorio sono due cose diverse

Un test di laboratorio, come Lighthouse, carica la tua pagina una volta su uno smartphone di fascia media simulato con una connessione rallentata. Puoi ripeterlo tutte le volte che vuoi ed è pieno di dettagli, ma il visitatore che descrive è immaginario.

I dati reali (field data) vengono da visite vere. Gli utenti di Chrome che hanno accettato di condividere le statistiche di utilizzo inviano tempi anonimi, e Google li aggrega sugli ultimi 28 giorni nel Chrome UX Report, noto come CrUX. Sono questi i dati che legge la Ricerca Google quando valuta l’esperienza sulla pagina. Una pagina può fare 95 in laboratorio e fallire comunque sul campo perché il suo pubblico reale usa smartphone più vecchi. Può anche passare sul campo con un punteggio di laboratorio mediocre perché la maggior parte dei visitatori arriva con la cache già piena.

Questo report chiede prima i dati reali, perché è la versione che conta.

I cinque tempi della tabella

Le prime tre sono i Core Web Vitals. FCP e TTFB sono in più perché aiutano a spiegare un LCP lento. Non contano per il voto.

Come è costruito il report

Seguiamo i reindirizzamenti fino all’indirizzo finale, poi interroghiamo CrUX due volte, una per gli smartphone e una per i desktop. Ogni interrogazione prova prima la pagina esatta e ripiega sull’intera origine quando la pagina da sola ha troppo poco traffico. La riga sopra ogni tabella dice quale dei due stai leggendo.

Il valore mostrato per una metrica è il suo 75° percentile: tre visite su quattro sono state almeno così veloci. La barra colorata accanto indica la quota di visite nelle fasce buona, da migliorare e scarsa.

Per il voto, ogni Core Web Vital vale 2 punti se buono, 1 se da migliorare e 0 se scarso. Sei punti su sei danno una A, cinque una B, quattro una C, tre una D, due una E e meno una F. Una sola metrica scarsa limita il voto a D, per quanto buone siano le altre due. Il voto principale è quello degli smartphone quando ci sono dati per gli smartphone.

Quando Chrome non ha dati

CrUX copre solo le pagine pubbliche e visitate abbastanza spesso. Per tutto il resto, il report esegue un test PageSpeed Insights su uno smartphone simulato e te lo dice chiaramente. Ottieni allora il punteggio di prestazioni Lighthouse (A da 90, B da 75, C da 50, D da 35, E da 20), i valori di laboratorio di LCP e CLS e il Total Blocking Time al posto di INP, perché non si può misurare la reattività all’input senza una persona che fa l’input. Sotto sono elencati fino a cinque audit con il maggior risparmio di tempo stimato.

Cosa fa muovere ogni numero

LCP

Trova l’elemento LCP nel pannello Performance di Chrome DevTools. Di solito è l’immagine principale. Servila alle dimensioni in cui viene mostrata, in WebP o AVIF, aggiungi fetchpriority="high" e non metterci mai loading="lazy". Se il TTFB supera già 0.8 s, sistema prima il server con la cache delle pagine o una CDN. L’analisi del peso della pagina mostra i file più pesanti.

INP

I task JavaScript lunghi impediscono alla pagina di rispondere all’input. Rimuovi i tag e i plugin che non usi più, carica gli script di terze parti con defer e spezza il lavoro che dura più di 50 ms.

CLS

Dai a ogni immagine e video gli attributi width e height, riserva spazio per annunci ed embed con min-height o aspect-ratio e non inserire banner sopra contenuti già visibili.

I dati reali sono una finestra mobile di 28 giorni. Dopo una correzione, i valori migliorano un po’ ogni giorno e servono quattro settimane per vederne l’effetto completo. Le visite da Safari e da qualsiasi browser su iPhone non fanno mai parte di CrUX, quindi il report descrive solo il tuo pubblico Chrome.