Scopri come attribuire i dati sul rendimento alle informazioni di debug per identificare e risolvere con Analytics i problemi degli utenti
Google offre due categorie di strumenti per misurare il rendimento ed eseguirne il debug:
- Strumenti di lab: strumenti come Lighthouse, in cui la pagina viene caricata in un ambiente simulato in grado di simulare varie condizioni (ad esempio, una rete lenta e un dispositivo mobile di fascia bassa).
- Strumenti sul campo: strumenti come il Chrome User Experience Report (CrUX), basato su dati aggregati e di utenti reali provenienti da Chrome. Tieni presente che i dati sul campo registrati da strumenti come PageSpeed Insights e Search Console provengono da dati di CrUX.
Sebbene gli strumenti sul campo offrano dati più accurati, che rappresentano effettivamente l'esperienza degli utenti reali, gli strumenti di laboratorio sono spesso più efficaci per identificare e risolvere i problemi.
I dati di CrUX sono più rappresentativi delle prestazioni reali della tua pagina, ma è improbabile che conoscere i tuoi punteggi CrUX ti aiuti a capire come migliorare le tue prestazioni.
Lighthouse, invece, individuerà i problemi e fornirà suggerimenti specifici per il miglioramento. Tuttavia, Lighthouse fornisce suggerimenti solo per i problemi di prestazioni rilevati al momento del caricamento della pagina. Non rileva i problemi che si manifestano solo in seguito all'interazione dell'utente, come lo scorrimento o i clic sui pulsanti della pagina.
Ciò solleva una domanda importante: come puoi acquisire informazioni di debug per Core Web Vitals o altre metriche sul rendimento da utenti reali sul campo?
Questo post illustra in dettaglio le API che puoi utilizzare per raccogliere ulteriori informazioni di debug per ciascuna delle metriche attuali di Core Web Vitals e ti fornisce 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, CLS è forse quella per cui la raccolta delle informazioni di debug sul campo è la più importante. Il CLS viene misurato durante l'intera vita utile della pagina, pertanto il modo in cui un utente interagisce con la pagina (la distanza di scorrimento, i clic e così via) può avere un impatto significativo sulla presenza di variazioni del layout e sugli elementi interessati.
Considera il seguente report di PageSpeed Insights:
Il valore riportato per CLS dal laboratorio (Lighthouse) rispetto al CLS dal campo (dati CrUX) è molto diverso e questo è logico se si considera che la pagina potrebbe avere molti contenuti interattivi che non vengono utilizzati durante il test in Lighthouse.
Ma anche se sei consapevole che l'interazione dell'utente influisce sui dati dei campi, devi comunque sapere quali elementi della pagina si stanno spostando per ottenere un punteggio di 0,28 al 75° percentile. Ciò è possibile grazie all'interfaccia LayoutShiftAttribution.
Ottieni l'attribuzione della variazione del layout
L'interfaccia LayoutShiftAttribution
è esposta su ogni voce layout-shift emessa dall'API Layout Instability.
Per una spiegazione dettagliata di entrambe le interfacce, consulta Eseguire il debug dei cambiamenti di layout. Ai fini di questo post, la cosa principale che devi sapere è che, in qualità di sviluppatore, sei in grado di osservare ogni variazione del layout che si verifica sulla pagina, nonché quali elementi stanno cambiando.
Ecco un codice di esempio che registra ogni variazione del layout, nonché gli elementi che sono stati modificati:
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 dati al tuo strumento di analisi per ogni singola variazione del layout che si verifica; tuttavia, monitorando tutte le variazioni, puoi tenere traccia delle variazioni peggiori e fornire solo informazioni su di esse.
L'obiettivo non è identificare e correggere ogni singola variazione del layout che si verifica per ogni utente, ma identificare le variazioni che interessano il maggior numero di utenti e che quindi contribuiscono maggiormente alla metrica CLS della pagina al 75° percentile.
Inoltre, non è necessario calcolare l'elemento di origine più grande ogni volta che si verifica un cambiamento, ma solo quando è tutto pronto per inviare il valore CLS allo strumento di analisi.
Il seguente codice prende un elenco di voci layout-shift che hanno contribuito al 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 più significativa, puoi segnalarlo al tuo strumento di analisi.
L'elemento che contribuisce maggiormente al CLS per una determinata pagina varierà probabilmente da un utente all'altro, ma se li raggruppi per tutti gli utenti, potrai generare un elenco di elementi mutevoli che interessano il maggior numero di utenti.
Dopo aver identificato e corretto la causa principale delle variazioni per questi elementi, il codice di analisi inizierà a registrare variazioni più piccole come quelle "peggiori" per le tue pagine. Alla fine, tutti i cambiamenti registrati saranno sufficientemente piccoli da far rientrare le tue pagine ben al di sotto della soglia "buona" di 0,1.
Alcuni altri metadati che potrebbero essere utili da acquisire insieme all'elemento di origine del cambiamento più grande sono:
- Il momento del turno più grande
- Il percorso dell'URL nel momento dello spostamento più grande (per i siti che aggiornano dinamicamente l'URL, ad esempio le applicazioni a pagina singola).
Largest Contentful Paint (LCP)
Per eseguire il debug dell'LCP nel campo, l'informazione principale di cui hai bisogno è quale particolare elemento è stato l'elemento più grande (l'elemento candidato LCP) per il caricamento pagina in questione.
Tieni presente che è del tutto possibile (in realtà è abbastanza comune) che l'elemento candidato LCP sia diverso da utente a utente, anche per la stessa pagina.
Questo può accadere per diversi motivi:
- I dispositivi degli utenti hanno risoluzioni dello schermo diverse, il che si traduce in diversi layout delle pagine e, di conseguenza, in elementi diversi visibili all'interno dell'area visibile.
- Gli utenti non caricano sempre le pagine fino in alto. Spesso i link contengono identificatori di frammenti o persino frammenti di testo, il che significa che è possibile caricare e visualizzare le pagine in qualsiasi posizione di scorrimento.
- I contenuti possono essere personalizzati in base all'utente corrente, quindi l'elemento candidato LCP potrebbe 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 misurarlo in base al comportamento degli utenti reali.
Identificare l'elemento candidato LCP
Per determinare l'elemento candidato LCP in JavaScript, puoi utilizzare l'API Largest Contentful Paint, la stessa API utilizzata per determinare il valore in millisecondi dell'LCP.
Quando osservi le voci largest-contentful-paint, puoi determinare
l'attuale elemento candidato LCP 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});
Una volta individuato l'elemento candidato LCP, puoi inviarlo allo strumento di analisi insieme al valore della metrica. Come per il CLS, questo ti aiuterà a identificare i elementi più importanti da ottimizzare per primi.
Oltre all'elemento candidato LCP, può essere utile misurare anche i tempi delle componenti secondarie LCP, che possono essere utili per determinare quali passaggi di ottimizzazione specifici 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 principali cause delle interazioni lente è un thread principale bloccato, che può essere comune durante il caricamento di JavaScript. Sapere se la maggior parte delle interazioni lente avviene durante il caricamento della pagina è utile per determinare cosa è necessario fare per risolvere il problema.
La metrica INP prende in considerazione la latenza completa di un'interazione, incluso il tempo necessario per eseguire gli ascoltatori di eventi registrati, nonché il tempo necessario per disegnare il frame successivo dopo l'esecuzione di tutti gli ascoltatori di eventi. Ciò significa che per l'INP è molto utile sapere quali elementi di destinazione tendono a generare interazioni lente e di che tipo di interazioni si tratta.
Il codice seguente 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 è la voce INP, poiché questa logica è più complessa. Tuttavia, la sezione seguente spiega come ottenere queste informazioni utilizzando la libreria JavaScript web-vitals.
Utilizzo con la libreria JavaScript web-vitals
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, la libreria JavaScript web-vitals include una costruzione di attribuzione che mostra tutte queste informazioni, oltre ad alcuni indicatori aggiuntivi.
Il seguente esempio di codice mostra come impostare un parametro evento aggiuntivo (o una dimensione personalizzata) contenente una stringa di debug utile per identificare la causa principale dei 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);
onINP(sendToGoogleAnalytics);
Questo codice è specifico per Google Analytics, ma l'idea generale dovrebbe essere applicabile anche ad altri strumenti di analisi.
Questo codice mostra anche come generare report su un singolo indicatore di debug, ma è utile poter raccogliere e generare report su più indicatori diversi per metrica.
Ad esempio, per eseguire il debug dell'INP, potresti voler raccogliere l'elemento con cui viene interagito, il tipo di interazione, il momento, lo stato di caricamento, le fasi di interazione e altro ancora (ad esempio i dati relativi ai frame di animazione lunghi).
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);
onINP(sendToGoogleAnalytics);
Per un elenco completo degli indicatori di debug esposti, consulta la documentazione sull'attribuzione web-vitals.
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 necessariamente ogni singolo problema riscontrato dagli utenti, ma è consigliabile risolvere, soprattutto all'inizio, i problemi che interessano il maggior numero di utenti, che dovrebbero essere anche quelli con l'impatto negativo maggiore sui tuoi punteggi Core Web Vitals.
Per GA4, consulta l'articolo dedicato su come eseguire query e visualizzare i dati utilizzando BigQuery.
Riepilogo
Ci auguriamo che questo post ti abbia aiutato a capire in che modo puoi utilizzare le API di rendimento esistenti e la libreria web-vitals per ottenere informazioni di debug utili per diagnosticare il rendimento in base alle visite degli utenti reali sul campo. Sebbene questa
guida sia incentrata sui Core Web Vitals, i concetti si applicano anche al debugging
di qualsiasi metrica sul rendimento misurabile in JavaScript.
Se hai appena iniziato a misurare il rendimento e sei già un utente di Google Analytics, lo strumento Report di Web Vitals potrebbe essere un buon punto di partenza perché supporta già la generazione di report sulle informazioni di debug per le metriche di Core Web Vitals.
Se sei un fornitore di soluzioni di analisi e stai cercando di migliorare i tuoi prodotti e fornire più informazioni di debug agli utenti, prendi in considerazione alcune delle tecniche qui descritte, 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 (e dovrebbero) acquisire e registrare 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 funzionalità o informazioni mancanti nelle API stesse, invia il tuo feedback a web-vitals-feedback@googlegroups.com.