Scopri perché gli strumenti che monitorano le metriche Core Web Vitals possono riportare numeri diversi e come interpretare queste differenze.
Google offre una serie di strumenti per aiutare i proprietari dei siti a monitorare i propri punteggi Core Web Vitals. Questi strumenti rientrano due categorie principali:
- Strumenti che registrano i dati di laboratorio, ovvero dati raccolti in un ambiente controllato con impostazioni predefinite del dispositivo e della rete.
- Strumenti che segnalano i dati sul campo: dati raccolti dagli utenti reali che visitano il sito. nel tuo sito.
Il problema è che a volte i dati riportati dagli strumenti di laboratorio possono essere diversi da quelli riportati dagli strumenti sul campo. I dati del lab potrebbero indicare che il rendimento del sito sia ottimo, ma i dati sul campo indicano che è necessario miglioramento. In alternativa, i dati dei campi possono indicare che tutte le pagine sono corrette, ma i dati del lab potrebbero indicare un punteggio molto basso.
Il seguente esempio reale di report PageSpeed Insights di web.dev mostra che in alcuni casi i dati di laboratorio e quelli sul campo possono essere diversi in tutti i team Metriche Web Vitals:
Le differenze tra gli strumenti sono una comprensibile fonte di confusione per sviluppatori. Questo post spiega i motivi principali per cui queste differenze esistono, con esempi specifici che coprono ciascuna delle metriche di Core Web Vitals, e cosa fare se rilevi differenze nelle tue pagine.
Confronto tra dati di laboratorio e dati sul campo
Per capire perché gli strumenti di laboratorio e sul campo potrebbero riportare valori diversi, anche per il è la stessa pagina web, devi capire la differenza tra lab e campo e i dati di Google Cloud.
Dati di laboratorio
I dati di laboratorio sono determinati caricando una pagina web in un ambiente controllato con un insieme predefinito di condizioni di rete e dispositivi. Queste condizioni sono note come lab, a volte definito anche ambiente sintetico.
Gli strumenti di Chrome che segnalano dati di lab sono generalmente in esecuzione Lighthouse.
Lo scopo di un test di laboratorio è controllare il maggior numero di fattori possibile, in modo che i risultati siano (per quanto possibile) coerenti e riproducibili dall'esecuzione all'esecuzione.
Dati sul campo
I dati dei campi vengono determinati monitorando tutti gli utenti che visitano una pagina e misurando un determinato insieme di metriche di rendimento per ciascuno di questi utenti individuale ed esperienze variegate. Poiché i dati dei campi si basano sulle visite di utenti reali, riflettono i dispositivi effettivi, le condizioni della rete e le posizioni geografiche degli utenti.
I dati sui campi sono noti anche come Monitoraggio utenti reali (RUM); i due termini sono intercambiabili.
Gli strumenti di Chrome che segnalano dati sul campo in genere ricevono questi dati dalla Report sull'esperienza utente (CrUX). È inoltre comune (e consigliato) i proprietari dei siti raccogliere dati dei campi perché può fornire più informazioni strategiche rispetto al semplice utilizzo di CrUX.
La cosa più importante da capire sui dati dei campi è che non si tratta solo è una distribuzione di numeri. Ciò significa che per alcune persone che visitano il tuo sito potrebbe caricarsi molto rapidamente, mentre per altri potrebbe caricarsi molto lentamente. I dati sul campo relativi al tuo sito sono l'insieme completo di tutti i dati sul rendimento raccolte dai tuoi utenti.
Ad esempio, i report CrUX mostrano una distribuzione delle metriche delle prestazioni rispetto a Utenti di Chrome 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 buona gli altri potrebbero avere un'esperienza molto negativa.
Se uno strumento riporta un solo numero per una determinata metrica, in genere rappresentano un punto specifico della distribuzione. Strumenti che segnalano Core Web I punteggi dei campi Vitals lo fanno utilizzando il 75° percentile.
Osservando l'LCP dai dati sul campo nello screenshot in alto, puoi vedere un di distribuzione in cui:
- L'88% delle visite ha registrato una LCP di 2,5 secondi o meno (buona).
- L'8% delle visite ha registrato una LCP tra 2,5 e 4 secondi (richiede miglioramenti).
- Il 4% delle visite ha registrato un valore LCP superiore a 4 secondi (scarso).
Al 75° percentile, LCP era di 1,8 secondi:
I dati di lab della stessa pagina mostrano un valore LCP di 3,0 secondi. Sebbene questo valore è superiore a 1,8 secondi indicato nei dati sul campo, si tratta comunque di un LCP valido valore per questa pagina; è uno dei tanti valori che compongono la distribuzione completa di esperienze di carico.
Perché i dati di prova controllati e reali sono diversi
Come spiegato nella sezione precedente, i dati di laboratorio e i dati sul campo misurano cose diverse.
I dati sul campo includono un'ampia varietà di condizioni di rete e dei dispositivi, nonché un di diversi tipi di comportamento degli utenti. Include inoltre eventuali altri fattori che incidono sull'esperienza utente, ad esempio ottimizzazioni del browser come cache back/forward (bfcache) o ottimizzazioni della piattaforma come Cache AMP.
Al contrario, i dati di laboratorio limitano intenzionalmente il numero di variabili interessate. R consiste in:
- Un solo dispositivo...
- connessa a una singola rete...
- eseguire da una singola posizione geografica.
I dettagli di un determinato test di laboratorio possono o meno rappresentare in modo accurato i 75° percentile di dati dei campi per una determinata pagina o un determinato sito.
L'ambiente controllato del lab è utile durante il debug di problemi o i test 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. Tu generalmente non registrano l'impatto sul rendimento del comportamento degli utenti reali, come scorrimento, selezione di testo o tocco di elementi sulla pagina.
Oltre alla possibile disconnessione tra le condizioni del lab e le condizioni della maggior parte degli utenti reali, esistono anche alcune differenze più sottili che è importante comprendere per dare il meglio al tuo lab e campi, nonché le eventuali differenze.
Le prossime sezioni approfondiranno i motivi, evidenziando i motivi più comuni. Potrebbero esserci differenze tra i dati di prova controllati e i dati reali di ciascuno dei team Metriche vitals:
LCP
Diversi elementi LCP
L'elemento LCP identificato in un test di laboratorio potrebbe non essere lo stesso LCP elemento visualizzato dagli utenti quando visitano la pagina.
Se esegui un report Lighthouse per una determinata pagina, verrà restituito lo stesso Elemento LCP ogni volta. Ma se esamini i dati dei campi per la stessa pagina, di solito sono presenti diversi elementi LCP, che dipendono da il numero di circostanze specifiche per ogni visita alla pagina.
Ad esempio, tutti i seguenti fattori potrebbero contribuire a un LCP diverso determinato per la stessa pagina:
- Dispositivi di dimensioni diverse comportano la visualizzazione di elementi diversi. all'interno dell'area visibile.
- Se l'utente ha eseguito l'accesso o se in alcune l'elemento LCP può essere molto diverso da un utente all'altro.
- Analogamente al punto precedente, un test A/B in esecuzione sulla pagina potrebbe comportano la visualizzazione di elementi molto diversi.
- L'insieme di caratteri installati nel sistema dell'utente può incidere sulle dimensioni del testo la pagina (e quindi l'elemento LCP).
- I test di laboratorio in genere vengono eseguiti sulla "base" di una pagina URL senza parametri di query o frammenti hash aggiunti. Nel mondo reale, però, gli utenti spesso condividono gli URL contenenti un identificatore di frammento frammento di testo, quindi l'elemento LCP può trovarsi effettivamente al centro o alla parte inferiore della pagina (anziché "sopra il piega").
Poiché l'LCP nel campo viene calcolato come il 75° percentile di tutte le visite degli utenti a una pagina, se una grande percentuale di questi utenti aveva un elemento LCP caricato molto rapidamente, ad esempio un paragrafo di testo reso con un carattere di sistema, anche se alcuni di questi utenti avevano come LCP un'immagine di grandi dimensioni che si carica lentamente , il punteggio della pagina potrebbe non essere influenzato se questo è inferiore al 25% dei visitatori.
In alternativa, potrebbe essere vero il contrario. Un test di laboratorio potrebbe identificare un blocco testo come elemento LCP perché emula un telefono Moto G4 che ha un relativamente piccola e inizialmente viene visualizzata l'immagine hero della pagina fuori dallo schermo. I dati dei campi, tuttavia, potrebbero includere principalmente utenti di Pixel XL con su schermi più grandi, quindi per loro l'immagine hero a caricamento lento è l'elemento LCP.
Effetti dello stato della cache su LCP
I test di laboratorio in genere caricano una pagina con una cache fredda, ma quando utenti reali la visitano è possibile che alcune delle sue risorse siano già state memorizzate nella cache.
La prima volta che un utente carica una pagina, potrebbe caricarsi lentamente, ma se la pagina ha corretta memorizzazione nella cache configurata, la volta successiva che l'utente restituisce pagina potrebbe caricarsi immediatamente.
Sebbene alcuni strumenti di lab supportano più esecuzioni della stessa pagina (per simulare per i visitatori di ritorno), non è possibile per uno strumento del lab in che percentuale le visite reali provengono da utenti nuovi e da utenti di ritorno.
I siti con configurazioni di cache ben ottimizzate e un numero elevato di visitatori abituali possono scoprire che l'LCP nel mondo reale è molto più veloce di quanto indicato dai dati di laboratorio.
Ottimizzazioni AMP o Signed Exchange
Siti creati con AMP o che utilizzano piattaforme Signed Exchange (SXG) possono essere precaricate da aggregatori di contenuti come Google Cerca. Ciò può portare a un rendimento di caricamento notevolmente migliore per gli utenti visitano le tue pagine da tali piattaforme.
Oltre al precaricamento multiorigine, i siti stessi possono precaricare i contenuti per le pagine successive del sito il che potrebbe migliorare l'LCP anche per quelle pagine.
Gli strumenti di laboratorio non simulano i risultati ottenuti con queste ottimizzazioni, e anche se non potevano sapere quale percentuale del traffico proviene piattaforme come la Ricerca Google rispetto ad altre fonti.
Effetti di bfcache sull'LCP
Quando le pagine vengono ripristinate dalla cache bfcache, l'esperienza di caricamento è quasi istantanea e queste esperienze sono incluse nel tuo campo i tuoi dati.
I test di laboratorio non prendono in considerazione bfcache, pertanto se le tue pagine vengono bfcache-friendly, probabilmente comportano punteggi LCP più rapidi riportati sul campo.
Effetti dell'interazione dell'utente sull'LCP
LCP identifica il tempo di rendering dell'immagine o del blocco di testo più grande nella visibile, ma l'elemento più grande può cambiare man mano che la pagina viene caricata o, se è vengono aggiunti in modo dinamico all'area visibile.
Nel lab, il browser attenderà che la pagina venga caricata completamente prima determinare quale fosse l'elemento LCP. Ma sul campo, il browser si fermerà e il monitoraggio degli elementi più grandi dopo che l'utente scorre la pagina o vi ha interagito.
Questo ha senso (ed è necessario) perché in genere gli utenti attendono interagire con una pagina fino a quando "viene visualizzata" vengono caricati, ovvero esattamente come vengono che una metrica punta a rilevare. Inoltre, non avrebbe senso prendere in considerazione gli elementi aggiunti nell'area visibile dopo l'interazione dell'utente, perché questi elementi potrebbero essere stati vengono caricati a causa di attività svolte dall'utente.
Il risultato, però, è che i dati dei campi per una pagina potrebbero essere più veloci volte LCP, a seconda del comportamento degli utenti sulla pagina.
INP
INP richiede l'interazione con un utente reale
La metrica INP misura il livello di reattività di una pagina alle interazioni degli utenti, nel momento in cui gli utenti hanno effettivamente scelto di interagire.
La seconda parte di questa frase è fondamentale perché esegue dei test di laboratorio, anche quelli che supporta il comportamento degli utenti dello script e non può prevedere con precisione quando gli utenti sceglieranno per interagire con una pagina, perciò non è possibile misurare accuratamente il FID.
TBT non considera il comportamento degli utenti
La metrica del lab Tempo di blocco totale (TBT) ha lo scopo di aiutare a diagnosticare i problemi con INP, in quanto quantifica in che misura il thread principale viene bloccato durante il caricamento della pagina.
L'idea è che le pagine con un grande codice JavaScript sincrono o altri le attività di rendering hanno più probabilità di avere un thread principale bloccato quando per prima cosa. Tuttavia, se gli utenti attendono di interagire con la pagina fino a dopo termina l'esecuzione di JavaScript, il valore INP potrebbe essere molto basso.
Il momento in cui gli utenti decidono di interagire con una pagina dipende in gran parte dal fatto che Sembra interattivo e questo valore non può essere misurato con TBT.
TBT non considera il ritardo con tocco
Se un sito non è ottimizzato per la visualizzazione mobile, i browser aggiungeranno 300 ms ritardo dopo un tocco prima di eseguire i gestori di eventi. Lo fanno perché devono Determina se l'utente sta tentando di toccare due volte lo zoom per attivare lo zoom eventi di mouse o clic.
Questo ritardo viene conteggiato ai fini dell'INP di una pagina perché contribuisce all'input reale la latenza minima richiesta dagli utenti. Ma poiché questo ritardo non è tecnicamente un Attività, non influisce sul TBT di una pagina. Ciò significa che una pagina potrebbe avere un INP scarso nonostante i punteggi TBT molto buoni.
Effetti dello stato della cache e di bfcache su INP
Allo stesso modo in cui una corretta memorizzazione nella cache può migliorare l'LCP sul campo, migliorare INP.
Nel mondo reale, un utente potrebbe avere il codice JavaScript di un sito già nel Cache, quindi l'elaborazione potrebbe richiedere meno di servizio, con conseguente minore ritardo.
Lo stesso vale anche per le pagine ripristinate da bfcache. In questi casi JavaScript viene ripristinato dalla memoria, pertanto l'elaborazione potrebbe essere scarsa o nulla nel tempo.
CLS
Effetti dell'interazione dell'utente sulla metrica CLS
La metrica CLS misurata nel lab prende in considerazione solo le variazioni del layout che si verificano sopra durante il caricamento, ma questo è solo un sottoinsieme di ciò che CLS e adottare misure correttive.
Sul campo, CLS prende in considerazione tutti i layout imprevisti cambiamenti che si verificano durante della pagina, inclusi i contenuti che cambiano man mano che l'utente scorre la pagina o risposta a richieste di rete lente dopo l'interazione dell'utente.
Ad esempio, capita spesso che le pagine eseguano il caricamento lento di immagini o iframe senza dimensioni e questo può causare errori di layout cambia quando un utente scorre fino a quelle sezioni della pagina. Ma questi cambiamenti potrebbero si verificano solo se l'utente scorre verso il basso, cosa che spesso non viene individuata in un test di laboratorio.
Contenuto personalizzato
I contenuti personalizzati, tra cui annunci mirati e test A/B, influiscono sugli elementi vengono caricati su una pagina. Influisce anche sul modo in cui vengono caricati, poiché spesso vengono caricati in un secondo momento e inseriti nei contenuti principali di una pagina, variazioni del layout.
Nel lab, di solito viene caricata una pagina senza contenuti personalizzati oppure con contenuti per un "utente di test" generico che può attivare o meno le variazioni a cui possono interessare gli utenti reali.
Poiché i dati sul campo includono le esperienze di tutti gli utenti, la quantità (e il grado) delle variazioni del layout riscontrate su una determinata pagina dipende molto dai contenuti viene caricato.
Effetti dello stato della cache e di bfcache su CLS
Due delle cause più comuni delle variazioni del layout durante il caricamento sono le immagini e iframe senza dimensioni (come indicato sopra) e caricamento lento caratteri ed entrambi questi problemi hanno maggiori probabilità influisce sull'esperienza la prima volta che un utente visita un sito, quando la cache viene vuoto.
Se le risorse di una pagina sono memorizzate nella cache o la pagina stessa viene ripristinata da bfcache, il browser di solito è in grado di eseguire il rendering di immagini e caratteri immediatamente, senza in attesa che vengano scaricati. Ciò può comportare valori CLS più bassi nel campo rispetto a quanto riportato da uno strumento di lab.
Che cosa fare quando i risultati sono diversi
Come regola generale, se per una determinata pagina disponi sia di dati dei campi sia di dati di laboratorio, è ciò che dovresti usare per assegnare le priorità alle tue iniziative. Dal momento che i dati dei campi rappresenta l'esperienza degli utenti reali ed è il modo più accurato per capire a cosa servono i tuoi utenti e cosa deve è migliorato.
D'altra parte, se i dati del campo mostrano buoni punteggi su tutta la linea, ma i dati di laboratorio suggeriscono che ci sono ancora margini di miglioramento, vale la pena per capire quali ulteriori ottimizzazioni possono essere fatte.
Inoltre, sebbene i dati sul campo acquisiscano le esperienze reali degli utenti, invece in modo che per gli utenti che riescono a caricare il sito. I dati di un lab possono a volte aiutano a individuare opportunità per espandere la copertura del sito e più accessibile per gli utenti con reti più lente o dispositivi di fascia bassa.
In generale, sia i dati di laboratorio che quelli sul campo sono parti importanti di una la misurazione del rendimento. Entrambi hanno punti di forza e limiti e se ne utilizzi solo uno potresti perdere l'opportunità di migliorare la migliore esperienza utente possibile.