Scopri perché gli strumenti che monitorano le metriche di Segnali web essenziali possono indicare numeri diversi e come interpretare queste differenze.
Google offre una serie di strumenti per aiutare i proprietari di siti a monitorare i propri punteggi di Segnali web essenziali. Questi strumenti rientrano in due categorie principali:
- Strumenti che segnalano i dati di lab: dati raccolti in un ambiente controllato con impostazioni predefinite del dispositivo e della rete.
- Strumenti che segnalano dati sul campo: dati raccolti da utenti reali che visitano il tuo sito.
Il problema è che a volte i dati riportati dagli strumenti di laboratorio possono essere un po' diversi da quelli riportati dagli strumenti sul campo. I dati di prova controllati potrebbero indicare che il sito ha prestazioni ottimali, ma i dati sul campo suggeriscono che deve essere migliorato. In alternativa, i dati sul campo potrebbero indicare che tutte le pagine sono corrette, mentre i dati di prova controllati potrebbero indicare un punteggio molto basso.
Il seguente esempio reale di un report PageSpeed Insights da web.dev mostra che in alcuni casi i dati di prova controllati e reali possono essere diversi in tutte le metriche di Segnali web essenziali:
Le differenze tra gli strumenti sono una comprensibile fonte di confusione per gli sviluppatori. Questo post spiega i motivi principali per cui potrebbero esistere queste differenze, con esempi specifici relativi a ciascuna delle metriche di Core Web Vitals e cosa fare se noti differenze nelle pagine.
Confronto tra dati di prova controllati e dati reali
Per capire perché gli strumenti da laboratorio e sul campo potrebbero segnalare valori diversi, anche per la stessa pagina web, devi capire la differenza tra i dati di laboratorio e quelli sul campo.
Dati di prova
I dati del lab vengono determinati caricando una pagina web in un ambiente controllato con un insieme predefinito di condizioni di rete e dispositivi. Queste condizioni sono note come ambiente lab o ambiente sintetico.
Gli strumenti di Chrome che segnalano i dati di lab generalmente eseguono Lighthouse.
Lo scopo di un test di laboratorio è controllare quanti più fattori possibile, affinché i risultati siano il più possibile coerenti e riproducibili dall'esecuzione all'esecuzione.
Dati dei campi
I dati dei campi vengono determinati monitorando tutti gli utenti che visitano una pagina e misurando un determinato insieme di metriche sul rendimento per ciascuna delle singole esperienze degli utenti. Poiché i dati dei campi si basano sulle visite degli utenti reali, riflettono i dispositivi effettivi, le condizioni della rete e le posizioni geografiche dei tuoi utenti.
I dati dei campi sono anche comunemente noti come dati RUM (Real User Monitoring). I due termini sono intercambiabili.
In genere, gli strumenti di Chrome che segnalano i dati sul campo ricevono questi dati dal Report sull'esperienza utente di Chrome (CrUX). Inoltre, è comune (e consigliato) per i proprietari di siti raccogliere da soli i dati sul campo, in quanto può fornire informazioni più strategiche rispetto al semplice utilizzo di CrUX.
La cosa più importante da capire dei dati dei campi è che non si tratta di un numero, ma di una distribuzione di numeri. Ciò significa che per alcuni utenti che visitano il sito potrebbe caricarsi molto rapidamente, mentre per altri potrebbe caricarsi molto lentamente. I dati dei campi per il tuo sito sono l'insieme completo di tutti i dati sul rendimento raccolti dagli utenti.
Ad esempio, i report CrUX mostrano una distribuzione di metriche sulle prestazioni di utenti di Chrome reali in un periodo di 28 giorni. Se esamini quasi tutti i report di CrUX, puoi notare che alcuni utenti che visitano un sito potrebbero avere un'esperienza molto positiva, mentre altri potrebbero avere un'esperienza molto negativa.
Se uno strumento riporta un singolo numero per una determinata metrica, di solito rappresenterà un punto specifico della distribuzione. Gli strumenti che segnalano i punteggi dei campi di Core Web Vitals lo fanno utilizzando il 75° percentile.
Osservando l'LCP dai dati dei campi 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 di durata compresa tra 2,5 e 4 secondi (da migliorare).
- Il 4% delle visite ha registrato un LCP superiore a 4 secondi (scarso).
Al 75° percentile, LCP era di 1,8 secondi:
I dati di prova controllati dalla stessa pagina mostrano un valore LCP di 3,0 secondi. Sebbene questo valore sia maggiore di 1,8 secondi mostrato nei dati del campo, è comunque un valore LCP valido per questa pagina, è uno dei molti valori che compongono l'intera distribuzione delle esperienze di carico.
Perché i dati di laboratorio e quelli sul campo sono diversi
Come spiegato nella sezione precedente, i dati di laboratorio e quelli sul campo misurano in realtà cose molto diverse.
I dati dei campi includono un'ampia varietà di condizioni di rete e dispositivi, nonché una miriade di diversi tipi di comportamento degli utenti. Sono inclusi anche altri fattori che influiscono sull'esperienza utente, come ottimizzazioni del browser come la cache back/forward (bfcache) o ottimizzazioni della piattaforma come la cache AMP.
Al contrario, i dati di prova controllati limitano intenzionalmente il numero di variabili coinvolte. Un test di laboratorio consiste in:
- Un singolo dispositivo...
- connesso a un'unica rete...
- vengono eseguiti da un'unica posizione geografica.
I dettagli di un determinato test di laboratorio potrebbero rappresentare o meno con precisione il 75° percentile dei dati sul campo per una determinata pagina o un determinato sito.
L'ambiente controllato del lab è utile per eseguire il debug dei problemi o testare le funzionalità prima del deployment in produzione, ma quando controlli questi fattori, non rappresenti esplicitamente la varianza che vedi nel mondo reale in tutti i tipi di reti, funzionalità del dispositivo o località geografiche. Inoltre, generalmente non si acquisiscono l'impatto sulle prestazioni del comportamento dell'utente reale, ad esempio lo scorrimento, la selezione del testo o il tocco di elementi sulla pagina.
Oltre alla possibile disconnessione tra le condizioni di laboratorio e le condizioni della maggior parte degli utenti reali, ci sono anche alcune differenze più sottili che sono importanti da comprendere per sfruttare al meglio i dati di laboratorio e sul campo, nonché eventuali differenze.
Le prossime sezioni verranno dettagliate e evidenziando i motivi più comuni per cui potrebbero esserci differenze tra i dati di laboratorio e i dati 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 che gli utenti vedono quando visitano la tua pagina.
Se esegui un report Lighthouse per una determinata pagina, questa restituisce ogni volta lo stesso elemento LCP. Tuttavia, se esamini i dati del campo per la stessa pagina, di solito troverai una varietà 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:
- A seconda delle dimensioni dello schermo dei dispositivi, elementi diversi sono visibili 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 utente a utente.
- Come per il punto precedente, l'esecuzione di un test A/B sulla pagina potrebbe comportare la visualizzazione di elementi molto diversi.
- Il set di caratteri installato nel sistema dell'utente può influenzare le dimensioni del testo nella pagina (e quindi quale elemento è l'elemento LCP).
- I test di lab vengono generalmente eseguiti sull'URL "base" di una pagina, senza l'aggiunta di parametri di query o frammenti hash. Tuttavia, nel mondo reale gli utenti spesso condividono URL che contengono un identificatore di frammento o un frammento di testo, per cui l'elemento LCP potrebbe trovarsi al centro o in fondo alla pagina (anziché "above the fold").
Poiché l'LCP nel campo viene calcolato come il 75° percentile di tutte le visite degli utenti a una pagina, se un'ampia percentuale di questi utenti presentasse un elemento LCP caricato 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 che si carica lentamente come elemento LCP, questo potrebbe non influire sul punteggio della pagina se questo accade a meno del 25%.
In alternativa, potrebbe essere vero il contrario. Un test di laboratorio potrebbe identificare un blocco di testo come elemento LCP perché emula un telefono Moto G4 con un'area visibile relativamente piccola e l'immagine hero della pagina viene inizialmente visualizzata fuori dallo schermo. I dati sul campo, tuttavia, potrebbero includere principalmente utenti di Pixel XL con schermi più grandi, quindi per loro l'immagine hero che si carica lentamente è il loro elemento LCP.
Effetti dello stato della cache sull'LCP
In genere, i test di lab caricano una pagina con cache a freddo, ma quando utenti reali la visitano, alcune delle sue risorse potrebbero essere già memorizzate nella cache.
La prima volta che un utente carica una pagina, questa potrebbe caricarsi lentamente, ma se per la pagina è stata configurata una corretta memorizzazione nella cache, la volta successiva che l'utente restituisce la pagina potrebbe caricarsi immediatamente.
Sebbene alcuni strumenti di lab supportino più esecuzioni della stessa pagina (per simulare l'esperienza per i visitatori di ritorno), non è possibile per uno strumento di lab sapere quale percentuale di visite nel mondo reale avviene da utenti nuovi rispetto a utenti di ritorno.
I siti con configurazioni della cache ben ottimizzate e molti visitatori abituali potrebbero scoprire che l'LCP reale è molto più veloce di quanto indicato dai dati di laboratorio.
Ottimizzazioni per AMP o Signed Exchange
I siti creati con AMP o che utilizzano Signed Exchange (SXG) possono essere precaricati da aggregatori di contenuti come la Ricerca Google. Ciò può migliorare notevolmente le prestazioni di caricamento per gli utenti che visitano le tue pagine da queste piattaforme.
Oltre al precaricamento multiorigine, i siti stessi possono precaricare i contenuti per le pagine successive del sito, il che potrebbe migliorare la metrica LCP anche per quelle pagine.
Gli strumenti di lab non simulano i guadagni ottenuti da queste ottimizzazioni e, anche se lo fossero, non potrebbero sapere quale percentuale di traffico proviene da piattaforme come la Ricerca Google rispetto ad altre sorgenti.
Effetti della cache back-forward sulla metrica LCP
Quando le pagine vengono ripristinate dalla cache back-forward, l'esperienza di caricamento è quasi istantanea e queste esperienze sono incluse nei dati sul campo.
I test di laboratorio non considerano la cache back-forward, quindi se le tue pagine sono compatibili con la cache back-forward, probabilmente otterrai punteggi LCP più veloci nel campo.
Effetti delle interazioni degli utenti sulla metrica LCP
Il valore LCP identifica il tempo di rendering dell'immagine o del blocco di testo più grande nel visualizzatore, ma l'elemento più grande può cambiare quando la pagina viene caricata o se nuovi contenuti vengono aggiunti dinamicamente all'area visibile.
Nel lab, il browser attenderà che la pagina venga caricata completamente prima di determinare quale fosse l'elemento LCP. Tuttavia, sul campo, il browser interrompe il monitoraggio degli elementi più grandi dopo che l'utente scorre la pagina o interagisce con la pagina.
Questo ha senso (ed è necessario) perché gli utenti in genere aspettano di interagire con una pagina fino a quando non "viene caricata", che è esattamente ciò che la metrica LCP cerca di rilevare. Inoltre, non avrebbe senso prendere in considerazione gli elementi aggiunti all'area visibile dopo che un utente ha interagito, perché questi elementi potrebbero essere stati caricati solo per ciò che ha fatto l'utente.
Ciò, tuttavia, comporta il fatto che i dati dei campi di una pagina potrebbero essere registrati più rapidamente, a seconda del comportamento degli utenti nella pagina.
FID
FID richiede l'interazione con l'utente reale
La metrica FID misura il livello di reattività di una pagina alle interazioni degli utenti, nel momento in cui gli utenti hanno effettivamente scelto di interagire con la pagina.
La seconda parte di questa frase è fondamentale perché i test di laboratorio, anche quelli che supportano il comportamento degli utenti di script, non possono prevedere con precisione quando gli utenti scelgono di interagire con una pagina e, pertanto, non possono misurare con precisione il FID.
TBT non prende in considerazione il comportamento degli utenti
La metrica del lab Tempo di blocco totale (TBT) aiuta a diagnosticare i problemi relativi al FID, in quanto quantifica quanto viene bloccato il thread principale durante il caricamento della pagina.
L'idea è che le pagine con molto codice JavaScript sincro o altre attività di rendering più impegnative hanno maggiori probabilità di avere un thread principale bloccato quando l'utente interagisce per la prima volta. Tuttavia, se gli utenti attendono di interagire con la pagina fino al termine dell'esecuzione di JavaScript, il valore FID potrebbe essere molto basso.
Il momento in cui gli utenti decideranno se interagire con una pagina dipende in gran parte dal fatto che la pagina sembri interattiva e questo non può essere misurato con TBT.
TBT non considera il ritardo del tocco
Se un sito non è ottimizzato per la visualizzazione sui dispositivi mobili, i browser aggiungeranno un ritardo di 300 ms dopo ogni tocco prima di eseguire i gestori di eventi. Lo fanno perché devono determinare se l'utente sta tentando di toccare due volte lo zoom prima di attivare eventi di clic o del mouse.
Questo ritardo viene conteggiato ai fini del FID di una pagina perché contribuisce alla latenza di input reale dell'esperienza degli utenti. Tuttavia, poiché questo ritardo non è tecnicamente un'attività lunga, non influisce sulla metrica TBT di una pagina. Ciò significa che una pagina potrebbe avere un valore FID basso nonostante i punteggi TBT molto buoni.
Effetti dello stato della cache e della cache back-forward su FID
Allo stesso modo in cui una memorizzazione nella cache corretta può migliorare l'LCP sul campo, può anche migliorare il FID.
Nel mondo reale, 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 back-forward. In questi casi, il codice JavaScript viene ripristinato dalla memoria, quindi i tempi di elaborazione potrebbero essere minimi o nulli.
CLS
Effetti dell'interazione dell'utente sulla metrica CLS
La metrica CLS misurata in lab prende in considerazione solo le variazioni del layout che si verificano above the fold e durante il caricamento, ma questo è solo un sottoinsieme di ciò che CLS misura effettivamente.
Nel campo, il CLS considera tutti i cambiamenti di layout imprevisti che si verificano durante la vita della pagina, inclusi i contenuti che cambiano man mano che l'utente scorre la pagina o in risposta a richieste di rete lente dopo l'interazione dell'utente.
Ad esempio, è piuttosto comune che le pagine carichino lentamente immagini o iframe senza dimensioni e ciò può causare variazioni del layout quando un utente scorre fino a quelle sezioni della pagina. Ma 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 annunci mirati e test A/B, influiscono sugli elementi caricati in una pagina. Inoltre, influisce 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 variazioni del layout.
Nel lab, di solito una pagina viene caricata senza contenuti personalizzati o con contenuti per un "utente di test" generico, il che potrebbe attivare o meno i cambiamenti che gli utenti reali vedono.
Poiché i dati sul campo includono le esperienze di tutti gli utenti, la quantità (e il grado) delle variazioni di layout che si verificano in una determinata pagina dipendono molto dai contenuti caricati.
Effetti dello stato della cache e della cache back-forward su CLS
Due delle cause più comuni delle variazioni del layout durante il caricamento sono le immagini e gli iframe senza dimensioni (come accennato in precedenza) e il caricamento lento dei caratteri web. Entrambi questi problemi hanno maggiori probabilità di interessare l'esperienza la prima volta che un utente visita un sito, quando la cache è vuota.
Se le risorse di una pagina sono memorizzate nella cache o se la pagina viene ripristinata dalla cache back-forward, il browser in genere è in grado di eseguire subito il rendering di immagini e caratteri, senza attendere il download. Ciò può comportare valori CLS più bassi nel campo rispetto a quanto riportato da uno strumento del lab.
Che cosa fare quando i risultati sono diversi
Come regola generale, se per una determinata pagina disponi sia di dati dei campi che di dati di prova controllati, devi utilizzare i dati dei campi per assegnare la priorità alle tue iniziative. Poiché i dati sul campo rappresentano ciò che gli utenti reali stanno affrontando, è il modo più preciso per capire davvero con cosa hanno difficoltà gli utenti e cosa deve essere migliorato.
D'altra parte, se i dati sul campo mostrano buoni punteggi su tutta la linea, ma i dati di prova controllati indicano che c'è ancora margine di miglioramento, vale la pena capire quali ulteriori ottimizzazioni possono essere apportate.
Inoltre, anche se i dati sul campo acquisiscono esperienze utente reali, lo fanno solo per gli utenti in grado di caricare correttamente il sito. I dati di prova controllati talvolta possono aiutarti a identificare le opportunità per espandere la copertura del tuo sito e renderlo più accessibile agli utenti con reti più lente o dispositivi di fascia bassa.
Nel complesso, sia i dati di laboratorio che quelli sul campo sono una parte importante per una misurazione efficace delle prestazioni. Entrambi hanno punti di forza e limiti e, se ne utilizzi solo uno, potresti perdere l'opportunità di migliorare l'esperienza degli utenti.