Scopri perché gli strumenti che monitorano le metriche di Core Web Vitals potrebbero riportare numeri diversi e come interpretare queste differenze.
Google fornisce diversi strumenti per aiutare i proprietari di siti a monitorare i propri punteggi Core Web Vitals. Questi strumenti rientrano in due categorie principali:
- Strumenti che generano report sui dati di laboratorio, ovvero dati raccolti in un ambiente controllato con impostazioni di rete e del dispositivo predefinite.
- Strumenti che generano report sui dati dei campi, ovvero i dati raccolti dagli utenti reali che visitano il tuo sito.
Il problema è che a volte i dati registrati dagli strumenti di laboratorio possono essere molto diversi da quelli registrati dagli strumenti sul campo. I dati di laboratorio potrebbero indicare che il tuo sito ha un ottimo rendimento, ma i dati sul campo suggeriscono che è necessario un miglioramento. In alternativa, i dati sul campo potrebbero indicare che tutte le pagine sono buone, ma i dati di laboratorio potrebbero riportare un punteggio molto basso.
Il seguente esempio reale di un report di PageSpeed Insights da web.dev mostra che in alcuni casi i dati di laboratorio e sul campo possono essere diversi in tutte le metriche di Core Web Vitals:
Le differenze tra gli strumenti sono una fonte di confusione comprensibile per gli sviluppatori. Questo post spiega i motivi principali per cui queste differenze potrebbero essere presenti, con esempi specifici che riguardano ciascuna delle metriche di Core Web Vitals, e cosa fare quando le trovi nelle tue pagine.
Dati di laboratorio e dati sul campo
Per capire perché gli strumenti di laboratorio e sul campo potrebbero riportare valori diversi, anche per la stessa pagina web, devi conoscere la differenza tra i dati di laboratorio e sul campo.
Dati di laboratorio
I dati di laboratorio vengono determinati caricando una pagina web in un ambiente controllato con un insieme predefinito di condizioni di rete e dispositivo. Queste condizioni sono note come ambiente di laboratorio, a volte definito anche ambiente sintetico.
Gli strumenti di Chrome che generano report sui dati di prova controllati in genere eseguono Lighthouse.
Lo scopo di un test di laboratorio è controllare il maggior numero possibile di fattori, in modo che i risultati siano (per quanto possibile) coerenti e riproducibili da un'esecuzione all'altra.
Dati sul campo
I dati dei campi vengono determinati monitorando tutti gli utenti che visitano una pagina e misurando una determinata serie di metriche sul rendimento per le singole esperienze di ciascun utente. Poiché i dati sul campo si basano sulle visite di utenti reali, riflettono i dispositivi, le condizioni di rete e le posizioni geografiche effettive degli utenti.
I dati sul campo sono noti anche come dati di monitoraggio degli utenti reali (RUM). I due termini sono intercambiabili.
Gli strumenti di Chrome che registrano i dati sul campo generalmente li ricavano dal Rapporto sull'esperienza utente di Chrome (CrUX). È inoltre comune (e consigliabile) che i proprietari di siti raccolgano autonomamente i dati sul campo, in quanto possono fornire approfondimenti più strategici rispetto all'utilizzo esclusivo di CrUX.
La cosa più importante da capire sui dati dei campi è che non si tratta solo di un numero, ma di una distribuzione di numeri. In altre parole, per alcuni utenti che visitano il tuo sito, il caricamento potrebbe essere molto rapido, mentre per altri potrebbe essere molto lento. I dati sul campo per il tuo sito sono il set completo di tutti i dati sul rendimento raccolti dai tuoi utenti.
Ad esempio, i report CrUX mostrano una distribuzione delle metriche sul rendimento degli utenti reali di Chrome in un periodo di 28 giorni. Se esamini quasi tutti i report CrUX, puoi vedere che alcuni utenti che visitano un sito potrebbero avere un'esperienza molto buona, mentre altri potrebbero avere un'esperienza molto negativa.
Se uno strumento riporta un singolo numero per una determinata metrica, in genere rappresenta un punto specifico della distribuzione. Gli strumenti che generano report sui punteggi dei campi Core Web Vitals lo fanno utilizzando la 75a mediana.
Se esamini il valore LCP dai dati sul campo nello screenshot sopra, puoi vedere una distribuzione in cui:
- L'88% delle visite ha registrato un valore LCP pari o inferiore a 2,5 secondi (buono).
- L'8% delle visite ha registrato un LCP compreso tra 2,5 e 4 secondi (richiede miglioramenti).
- Il 4% delle visite ha registrato un LCP superiore a 4 secondi (risultato scadente).
Al 75° percentile, il valore LCP era di 1,8 secondi:
I dati di laboratorio della stessa pagina mostrano un valore LCP di 3,0 secondi. Sebbene questo valore sia superiore agli 1,8 secondi mostrati nei dati sul campo, è comunque un valore LCP valido per questa pagina, uno dei molti valori che compongono la distribuzione completa delle esperienze di caricamento.
Perché i dati di laboratorio e sul campo sono diversi
Come spiegato nella sezione precedente, i dati di laboratorio e i dati sul campo misurano in realtà cose molto diverse.
I dati sul campo includono una vasta gamma di condizioni di rete e dispositivo, nonché una miriade di diversi tipi di comportamento degli utenti. Sono inclusi anche altri fattori che influiscono sull'esperienza utente, come le ottimizzazioni del browser, ad esempio la cache avanti/indietro (bfcache), o le ottimizzazioni della piattaforma, ad esempio la cache AMP.
Al contrario, i dati di laboratorio limitano intenzionalmente il numero di variabili coinvolte. Un test di laboratorio è costituito da:
- Un singolo dispositivo…
- connesso a una singola rete…
- vengono eseguiti da una singola località geografica.
I dettagli di un determinato test di laboratorio possono o meno rappresentare con precisione il 75° percentile dei dati sul campo per una determinata pagina o un determinato sito.
L'ambiente controllato del laboratorio è utile per risolvere i problemi di debug o testare le funzionalità prima del deployment in produzione, ma quando controlli questi fattori, non rappresenti esplicitamente la varianza che vedi nel mondo reale su tutti i tipi di reti, funzionalità dei dispositivi o posizioni geografiche. Inoltre, in genere non viene rilevato l'impatto sul rendimento del comportamento degli utenti reali, come lo scorrimento, la selezione del testo o il tocco di elementi nella pagina.
Oltre alla possibile disconnessione tra le condizioni di laboratorio e quelle della maggior parte degli utenti reali, esistono anche una serie di differenze più sottili che è importante comprendere per ottenere il massimo dai dati di laboratorio e sul campo, nonché da eventuali differenze che potresti riscontrare.
Le sezioni successive descrivono in dettaglio i motivi più comuni per cui potrebbero esserci differenze tra i dati di laboratorio e quelli sul campo per ciascuna delle metriche di Core Web Vitals:
LCP
Elementi LCP diversi
L'elemento LCP identificato in un test di laboratorio potrebbe non essere lo stesso elemento LCP visualizzato dagli utenti quando visitano la tua pagina.
Se esegui un report Lighthouse per una determinata pagina, verrà restituito lo stesso elemento LCP ogni volta. Tuttavia, se esamini i dati del campo per la stessa pagina, solitamente troverai una serie di elementi LCP diversi, che dipendono da una serie di circostanze specifiche per ogni visita alla pagina.
Ad esempio, i seguenti fattori potrebbero contribuire a determinare un elemento LCP diverso per la stessa pagina:
- Le dimensioni dello schermo dei dispositivi diverse comportano la visualizzazione di elementi diversi all'interno dell'area visibile.
- Se l'utente ha eseguito l'accesso o se in qualche modo vengono mostrati contenuti personalizzati, l'elemento LCP potrebbe essere molto diverso da un utente all'altro.
- Come nel punto precedente, se nella pagina è in esecuzione un test A/B, potrebbe essere visualizzato un insieme di elementi molto diverso.
- L'insieme di caratteri installati sul sistema dell'utente può influire sulle dimensioni del testo sulla pagina (e quindi su quale elemento è l'elemento LCP).
- I test di laboratorio vengono in genere eseguiti sull'URL "di base" di una pagina, senza parametri di query o frammenti di hash aggiunti. Tuttavia, nella realtà, gli utenti condividono spesso URL contenenti un identificatore di frammento o un frammento di testo, pertanto l'elemento LCP potrebbe essere effettivamente nella parte centrale o inferiore della pagina (anziché "sopra la piega").
Poiché il valore LCP nel campo viene calcolato come il 75° percentile di tutte le visite degli utenti a una pagina, se una percentuale elevata di questi utenti aveva un elemento LCP che si caricava molto rapidamente, ad esempio un paragrafo di testo visualizzato con un carattere di sistema, anche se alcuni di questi utenti avevano un'immagine di grandi dimensioni con un caricamento lento come elemento LCP, questo potrebbe non influire sul punteggio della pagina se si verifica per meno del 25% di visitatori.
In alternativa, potrebbe essere vero il contrario. Un test di laboratorio potrebbe identificare un blocco di testo come elemento LCP perché emula uno smartphone Moto G4 con un'area visibile relativamente piccola e l'immagine hero della pagina viene inizialmente visualizzata fuori dallo schermo. I tuoi dati sul campo, tuttavia, potrebbero includere principalmente utenti di Pixel XL con schermi più grandi, per i quali l'immagine hero con caricamento lento è l'elemento LCP.
Effetti dello stato della cache sull'LCP
In genere, i test di laboratorio caricano una pagina con una cache non attiva, ma quando gli utenti reali visitano la pagina, alcune delle sue risorse potrebbero essere già memorizzate nella cache.
La prima volta che un utente carica una pagina, il caricamento potrebbe essere lento, ma se la pagina ha una memorizzazione nella cache configurata correttamente, la volta successiva che l'utente torna sulla pagina, la pagina potrebbe caricarsi immediatamente.
Sebbene alcuni strumenti di laboratorio supportino più esecuzioni della stessa pagina (per simulare l'esperienza per i visitatori di ritorno), non è possibile per uno strumento di laboratorio sapere quale percentuale di visite reali proviene da utenti nuovi rispetto a quelli di ritorno.
I siti con configurazioni della cache ben ottimizzate e molti visitatori abituali potrebbero scoprire che il loro LCP reale è molto più veloce di quanto indicato dai dati di laboratorio.
Ottimizzazioni AMP o Signed Exchange
I siti creati con AMP o che utilizzano Signed Exchange (SXG) possono essere precaricati dagli aggregatori di contenuti come la Ricerca Google. Ciò può comportare un miglioramento significativo del rendimento del caricamento per gli utenti che visitano le tue pagine da queste piattaforme.
Oltre al precaricamento cross-origin, i siti stessi possono precaricare i contenuti per le pagine successive sul proprio sito, il che potrebbe migliorare anche l'LCP per queste pagine.
Gli strumenti di laboratorio non simulano i vantaggi ottenuti da queste ottimizzazioni e, anche se lo facessero, non potrebbero sapere quale percentuale del tuo traffico proviene da piattaforme come la Ricerca Google rispetto ad altre sorgenti.
Effetti della cache bfcache sull'LCP
Quando le pagine vengono ripristinate dalla bfcache, l'esperienza di caricamento è quasi istantanea e queste esperienze sono incluse nei dati di campo.
I test di laboratorio non prendono in considerazione la bfcache, quindi se le tue pagine sono compatibili con la bfcache, è probabile che i punteggi LCP registrati sul campo siano più rapidi.
Effetti dell'interazione degli utenti sull'LCP
LCP identifica il tempo di rendering dell'immagine o del blocco di testo più grande nell'area visibile, ma questo elemento più grande può cambiare durante il caricamento della pagina o se nuovi contenuti vengono aggiunti dinamicamente all'area visibile.
Nel lab, il browser attenderà il caricamento completo della pagina prima di determinare quale sia l'elemento LCP. Tuttavia, in questo caso il browser interromperà il monitoraggio degli elementi più grandi dopo che l'utente avrà interagito con la pagina o averla sbloccata.
Questo è logico (ed è necessario) perché in genere gli utenti aspettano di interagire con una pagina finché non "sembra" caricata, che è esattamente ciò che la metrica LCP si propone di rilevare. Inoltre, non avrebbe senso prendere in considerazione gli elementi aggiunti al viewport dopo l'interazione di un utente, perché potrebbero essere stati caricati solo a causa di un'azione dell'utente.
Ciò significa che i dati sul campo di una pagina possono registrare tempi LCP più rapidi, a seconda del comportamento degli utenti in quella pagina.
INP
L'INP richiede l'interazione di utenti reali
La metrica INP misura l'adattabilità di una pagina alle interazioni degli utenti, nel momento in cui gli utenti hanno effettivamente scelto di interagire con essa.
La seconda parte della frase è fondamentale perché i test di laboratorio, anche quelli che supportano il comportamento degli utenti dello script, non possono prevedere con precisione quando gli utenti sceglieranno di interagire con una pagina e, di conseguenza, non possono misurare con precisione il FID.
La TBT non prende in considerazione il comportamento degli utenti
La metrica di laboratorio Total Blocking Time (TBT) è progettata per aiutare a diagnosticare i problemi relativi all'INP perché quantifica il grado di blocco del thread principale durante il caricamento della pagina.
L'idea è che le pagine con molto codice JavaScript sincrono o altre attività di rendering intensive hanno maggiori probabilità di avere un thread principale bloccato quando l'utente interagisce per la prima volta. Tuttavia, se gli utenti aspettano di interagire con la pagina fino al termine dell'esecuzione di JavaScript, l'INP potrebbe essere molto basso.
Il momento in cui gli utenti scelgono di interagire con una pagina dipende in gran parte dal fatto che la pagina sembra interattiva o meno e questo non può essere misurato con il TBT.
Il TBT non prende in considerazione il ritardo del tocco
Se un sito non è ottimizzato per la visualizzazione da dispositivo mobile, i browser aggiungono un ritardo di 300 ms dopo ogni tocco prima di eseguire i gestori degli eventi. Lo fanno perché devono determinare se l'utente sta cercando di toccare due volte per aumentare lo zoom prima di poter attivare gli eventi del mouse o del clic.
Questo ritardo viene conteggiato ai fini dell'INP di una pagina perché contribuisce alla latenza di input reale riscontrata dagli utenti. Tuttavia, poiché questo ritardo non è tecnicamente una task lunga, non influisce sul TBT di una pagina. Ciò significa che una pagina potrebbe avere un INP basso nonostante abbia punteggi TBT molto buoni.
Effetti dello stato della cache e di bfcache sull'INP
Allo stesso modo in cui una corretta memorizzazione nella cache può migliorare il tempo di caricamento percepito sul campo, può anche migliorare l'INP.
Nella realtà, un utente potrebbe avere già il codice JavaScript di un sito nella cache, quindi l'elaborazione potrebbe richiedere meno tempo e comportare ritardi minori.
Lo stesso vale per le pagine ripristinate dalla cache bfcache. In questi casi, il codice JavaScript viene ripristinato dalla memoria, quindi il tempo di elaborazione potrebbe essere ridotto al minimo o addirittura nullo.
CLS
Effetti dell'interazione utente sul CLS
Il CLS misurato in laboratorio prende in considerazione solo le variazioni del layout che si verificano sopra la piega e durante il caricamento, ma si tratta solo di un sottoinsieme di ciò che misura effettivamente il CLS.
Sul campo, il CLS prende in considerazione tutte le variazioni di layout impreviste che si verificano durante la vita della pagina, inclusi i contenuti che si spostano mentre l'utente scorre o in risposta a richieste di rete lente dopo l'interazione dell'utente.
Ad esempio, è abbastanza comune che le pagine caricino immagini o iframe con il caricamento differito senza dimensioni, il che può causare cambiamenti nel layout quando un utente scorre fino a quelle sezioni della pagina. Tuttavia, questi cambiamenti possono verificarsi solo se l'utente scorre verso il basso, il che spesso non viene rilevato in un test di laboratorio.
Contenuto personalizzato
I contenuti personalizzati, inclusi gli annunci mirati e i test A/B, influiscono sugli elementi caricati su una pagina. Influisce anche sul modo in cui vengono caricati, poiché i contenuti personalizzati vengono spesso caricati in un secondo momento e inseriti nei contenuti principali di una pagina, causando cambiamenti nel layout.
In genere, in laboratorio una pagina viene caricata senza contenuti personalizzati o con contenuti per un "utente di test" generico, il che può o meno attivare i cambiamenti che vedono gli utenti reali.
Poiché i dati sul campo includono le esperienze di tutti gli utenti, la quantità (e il grado) di cambiamenti di layout riscontrati in una determinata pagina dipende molto dai contenuti caricati.
Effetti dello stato della cache e di bfcache sul CLS
Due delle cause più comuni dei cambiamenti di layout durante il caricamento sono le immagini e gli iframe senza dimensioni (come indicato sopra) e i caratteri web con caricamento lento. Entrambi questi problemi hanno maggiori probabilità di influire sull'esperienza la prima volta che un utente visita un sito, quando la cache è vuota.
Se le risorse di una pagina vengono memorizzate nella cache o se la pagina stessa viene ripristinata da BFCache, in genere il browser può visualizzare immediatamente immagini e caratteri, senza dover attendere il loro download. Ciò può comportare valori CLS inferiori nel campo rispetto a quelli riportati da uno strumento di laboratorio.
Cosa fare quando i risultati sono diversi
Come regola generale, se hai sia dati sul campo che dati di laboratorio per una determinata pagina, devi utilizzare i dati sul campo per dare la priorità alle tue attività. Poiché i dati sul campo rappresentano l'esperienza degli utenti reali, sono il modo più accurato per capire davvero i problemi che gli utenti riscontrano e cosa deve essere migliorato.
Al contrario, se i dati sul campo mostrano buoni punteggi in generale, ma i dati di laboratorio suggeriscono che c'è ancora margine di miglioramento, vale la pena capire quali ulteriori ottimizzazioni possono essere apportate.
Inoltre, sebbene i dati dei campi acquisiscano le esperienze degli utenti reali, lo fanno solo per gli utenti che riescono a caricare il tuo sito. A volte i dati di laboratorio possono aiutarti a identificare opportunità per espandere la copertura del tuo sito e renderlo più accessibile agli utenti con reti più lente o dispositivi di fascia bassa.
In generale, sia i dati di laboratorio sia quelli sul campo sono componenti importanti di una misurazione del rendimento efficace. Entrambi hanno i loro punti di forza e le loro limitazioni e, se ne utilizzi solo uno, potresti perdere un'opportunità per migliorare l'esperienza dei tuoi utenti.