Scopri come attribuire i dati sul rendimento alle informazioni di debug per aiutarti a identificare e risolvere i problemi degli utenti reali con Analytics
Google offre due categorie di strumenti per misurare il rendimento ed eseguirne il debug:
- Strumenti di Labs: strumenti come Lighthouse, dove la pagina viene caricata in un un ambiente simulato in grado di imitare varie condizioni (ad esempio, una rete mobile e un dispositivo mobile di fascia bassa).
- Strumenti sul campo: strumenti quali Esperienza utente di Chrome Segnala (CrUX), basato su dati aggregati di utenti reali provenienti da Chrome. Tieni presente che dati dei campi segnalati da strumenti come PageSpeed Approfondimenti e Ricerca Console proviene da dati di CrUX).
Mentre gli strumenti sul campo offrono dati più accurati, che rappresentano effettivamente ciò esperienza utente reale: gli strumenti di laboratorio sono spesso più utili per identificare e risolvere che le applicazioni presentino problemi di prestazioni.
I dati di CrUX sono più rappresentativi del rendimento reale della tua pagina, ma sapendo è improbabile che i punteggi CrUX ti aiutino a capire come migliorare delle prestazioni.
Lighthouse, invece, identificherà i problemi e fornirà specifiche suggerimenti per migliorare. Tuttavia, Lighthouse fornisce solo suggerimenti per i problemi di prestazioni rilevati al tempo di caricamento della pagina. Non rileva problemi che si manifestano solo in seguito a un'interazione dell'utente, ad esempio lo scorrimento o i clic pulsanti sulla pagina.
Ciò solleva una domanda importante: come si possono acquisire le informazioni di debug per Core Web Vitals o altre metriche sulle prestazioni di utenti reali sul campo?
Questo post spiegherà in dettaglio quali API puoi utilizzare per raccogliere ulteriori le informazioni di debug per ciascuna delle attuali metriche di Core Web Vitals e fornisce trovare idee su come acquisire questi dati nello strumento di analisi esistente.
API per l'attribuzione e il debug
Cumulative Layout Shift (CLS)
Di tutte le metriche Core Web Vitals, la metrica CLS è forse quella per cui la raccolta delle informazioni di debug sul campo è la più importante. La metrica CLS viene misurata durante l'intera durata della pagina, quindi il modo in cui un utente interagisce pagina (la distanza dello scorrimento, i clic su cui fanno clic e così via) possono avere un significativo l'impatto sull'eventuale presenza di variazioni del layout e su quali elementi stanno cambiando.
Considera il seguente report di PageSpeed Insights:
Il valore riportato per la metrica CLS del lab (Lighthouse) rispetto alla CLS di campo (dati CrUX) sono molto diversi, e questo ha senso se si considerano la pagina potrebbe includere molti contenuti interattivi non viene utilizzato durante il test in Lighthouse.
Ma anche se sei consapevole che l'interazione dell'utente influisce sui dati dei campi, devi sapere quali elementi della pagina si spostano per ottenere un punteggio pari a 0,28. al 75° percentile. Il campo LayoutShiftAttribution questo è possibile.
Ottieni l'attribuzione della variazione del layout
Il campo LayoutShiftAttribution
è esposta su ogni voce layout-shift che presenta instabilità del layout
dell'API.
Per una spiegazione dettagliata di entrambe le interfacce, consulta Layout di debug senza interruzioni. Ai fini di: da questo post, la cosa principale da sapere è che, in qualità di sviluppatore, di osservare tutte le variazioni del layout che si verificano nella pagina e quali elementi stanno cambiando.
Ecco un esempio di codice che registra ogni variazione del layout e gli elementi che ha subito una variazione:
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
Probabilmente non è pratico misurare e inviare i dati allo strumento di analisi per ogni singola variazione del layout che si verifica; Tuttavia, monitorando tutti i cambiamenti, è in grado di tenere traccia dei cambiamenti peggiori e di fornire informazioni in merito.
L'obiettivo non è identificare e correggere ogni singola variazione del layout che si verifica ogni utente; l'obiettivo è identificare i cambiamenti che interessano il maggior numero di utenti e quindi contribuiscono maggiormente alla metrica CLS della tua pagina al 75° percentile.
Inoltre, non devi calcolare l'elemento di origine più grande ogni volta che è presente una di spostamento, devi farlo solo quando sei pronto a inviare il valore CLS al tuo di analisi dei dati.
Il seguente codice accetta un elenco di layout-shift voci che hanno contribuito
in CLS e restituisce l'elemento di origine più grande dalla variazione più grande:
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
Una volta identificato l'elemento più importante che contribuisce alla variazione maggiore, puoi segnalarlo al tuo strumento di analisi.
L'elemento che contribuisce maggiormente alla CLS per una determinata pagina varierà probabilmente da da utente a utente, ma se aggreghi questi elementi tra tutti gli utenti, otterrai in grado di generare un elenco di elementi mutevoli che interessano il maggior numero di utenti.
Dopo aver identificato e corretto la causa principale delle variazioni di quelle , il codice di Analytics inizierà a segnalare le variazioni più piccole come "peggiori" per le tue pagine. In seguito, tutti i turni riportati saranno sufficientemente ridotti da le tue pagine si trovino all'interno dello "Buono" soglia di 0,1!
Alcuni altri metadati che potrebbero essere utili da acquisire insieme alla variazione più ampia l'elemento di origine è:
- Il momento del turno più grande
- Il percorso dell'URL nel momento della variazione maggiore (per i siti che aggiornare l'URL, ad esempio applicazioni a pagina singola).
Largest Contentful Paint (LCP)
Per eseguire il debug LCP nel campo, le informazioni principali di cui hai bisogno sono è l'elemento più grande (l'elemento candidato LCP) per quel particolare caricamento pagina.
Tieni presente che è del tutto possibile (in effetti, è abbastanza comune) che l'LCP l'elemento candidato sarà diverso da un utente all'altro, anche per lo stesso .
Questo può accadere per diversi motivi:
- I dispositivi degli utenti hanno risoluzioni dello schermo diverse, il che comporta layout di pagina e quindi elementi diversi visibili all'interno dell'area visibile.
- Gli utenti non sempre caricano le pagine scorrendo fino in cima. Spesso i link Contengono identificatori di frammenti o anche frammenti di testo, il che significa che è possibile per caricare e visualizzare le pagine in qualsiasi posizione di scorrimento della pagina.
- I contenuti possono essere personalizzati per l'utente corrente, pertanto l'elemento candidato LCP può variare notevolmente da utente a utente.
Ciò significa che non è possibile fare ipotesi su quale elemento o insieme di elementi sarà l'elemento candidato LCP più comune per una determinata pagina. Devi misurarle in base al comportamento degli utenti reali.
Identificare l'elemento candidato LCP
Per determinare l'elemento candidato LCP in JavaScript, puoi utilizzare lo strumento l'API Contentful Paint, la stessa API che usi per determinare il valore temporale LCP.
Quando osservi le voci largest-contentful-paint, puoi determinare
elemento candidato LCP attuale osservando la proprietà element dell'ultima voce:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
Quando conosci l'elemento candidato LCP, puoi inviarlo al tuo strumento di analisi insieme al valore della metrica. Come per CLS, questo ti aiuterà a identificare quali è più importante ottimizzare per primi.
Oltre all'elemento candidato LCP, può essere utile misurare anche Tempi parziali LCP, che possono essere utili nel determinare quali fasi di ottimizzazione specifiche sono pertinenti per il tuo sito.
Interaction to Next Paint (INP)
Le informazioni più importanti da acquisire sul campo per INP sono:
- Con quale elemento è stata eseguita l'interazione
- Perché il tipo di interazione è stato
- Quando si è verificata l'interazione
Una delle cause principali delle interazioni lente è il blocco del thread principale, che può essere comuni durante il caricamento di JavaScript. Sapere se le interazioni più lente sono che si verificano durante il caricamento della pagina è utile per determinare cosa è necessario fare per risolvere il problema.
La metrica INP considera la latenza completa di un interazione, incluso il tempo necessario per eseguire qualsiasi listener di eventi registrato come nonché il tempo necessario per visualizzare il frame successivo dopo che sono stati ascoltati tutti gli eventi sono state eseguite. Ciò significa che per INP è molto utile sapere quale target di elementi tendono a causare interazioni lente e quali tipi di interazioni questi sono.
Il seguente codice registra l'elemento target e l'ora della voce INP.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
Tieni presente che questo codice non mostra come determinare quale voce event è l'INP
poiché questa logica è più coinvolta. Tuttavia, la sezione che segue spiega
come ottenere queste informazioni utilizzando
nella libreria JavaScript web-vitals.
Utilizzo con la libreria JavaScript Webvitals
Le sezioni precedenti offrono alcuni suggerimenti generali ed esempi di codice per acquisire informazioni di debug da includere nei dati inviati allo strumento di analisi.
Dalla versione 3, gli elementi web-vitals La libreria JavaScript include un'attribuzione per creare mostra tutte queste informazioni e alcune altre indicatori.
Il seguente esempio di codice mostra come impostare un evento aggiuntivo parametro (o personalizzato ) contenente una stringa di debug utile per aiutare a identificare la causa principale delle prestazioni che le applicazioni presentino problemi di prestazioni.
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Questo codice è specifico per Google Analytics, ma l'idea generale dovrebbe con altri strumenti di analisi.
Questo codice mostra anche come generare report su un singolo indicatore di debug, essere in grado di raccogliere e generare report su più indicatori diversi per o una metrica di valutazione.
Ad esempio, per eseguire il debug di INP, potresti voler raccogliere l'elemento ha interagito, il tipo di interazione, l'ora, il loadState, l'interazione fasi e altro ancora (come i dati dei frame dell'animazione lunga).
La build dell'attribuzione web-vitals mostra ulteriori informazioni sull'attribuzione,
come mostrato nell'esempio seguente per INP:
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Fai riferimento all'attribuzione delle vitali web documentazione per gli elenco completo degli indicatori di debug esposti.
Crea report e visualizza i dati
Dopo aver iniziato a raccogliere le informazioni di debug insieme ai valori delle metriche, il passaggio successivo consiste nell'aggregare i dati di tutti gli utenti per iniziare a cercare schemi e tendenze.
Come accennato in precedenza, non è necessario risolvere ogni singolo problema che gli utenti stanno incontrando, è importante risolvere, soprattutto, i problemi che interessano il maggior numero di utenti, il che dovrebbe essere anche il problema che hanno il maggiore impatto negativo sui tuoi punteggi Core Web Vitals.
Per GA4 consulta l'articolo dedicato su come eseguire query e visualizzare i dati utilizzando BigQuery.
Riepilogo
Spero che questo post ti abbia aiutato a chiarire i modi specifici in cui puoi utilizzare
le API per le prestazioni esistenti e la libreria web-vitals per ottenere informazioni di debug
per diagnosticare il rendimento in base alle visite di utenti reali sul campo. Anche se questo
è incentrata sui Core Web Vitals, i concetti si applicano anche al debug
qualsiasi metrica di rendimento misurabile in JavaScript.
Se hai appena iniziato a misurare il rendimento e sei già un utente di Google Analytics, lo strumento di report Web Vitals può essere un buon punto di partenza. in quanto supporta già la generazione di report sulle informazioni di debug per il core web Metriche Vitals.
Se sei un fornitore di soluzioni di analisi e ti interessa migliorare i tuoi prodotti e ulteriori informazioni di debug, considera alcuni dei tecniche descritte qui, ma non limitarti solo alle idee presentate qui. Questo post è pensato per essere generalmente applicabile a tutti gli strumenti di analisi; Tuttavia, è probabile che i singoli strumenti di analisi possano acquisire e generare report e ancora più informazioni di debug.
Infine, se ritieni che ci siano delle lacune nella tua capacità di eseguire il debug di queste metriche a causa di informazioni o funzionalità mancanti nelle API, invia il tuo feedback a web-vitals-feedback@googlegroups.com.