Scopri come attribuire i dati sul rendimento con informazioni di debug per identificare e risolvere i problemi degli utenti reali con Analytics
Google fornisce due categorie di strumenti per misurare ed eseguire il debug delle prestazioni:
- Strumenti di laboratorio:strumenti come Lighthouse, in cui la pagina viene caricata in un ambiente simulato che può imitare varie condizioni (ad esempio, una rete lenta e un dispositivo mobile di fascia bassa).
- Strumenti sul campo:strumenti come il Report sull'esperienza utente di Chrome (CrUX), basato su dati aggregati di utenti reali di Chrome. Tieni presente che i dati sul campo riportati da strumenti come PageSpeed Insights e Search Console provengono dai dati CrUX.
Mentre gli strumenti sul campo offrono dati più accurati, che rappresentano effettivamente l'esperienza degli utenti reali, gli strumenti di laboratorio sono spesso più utili per identificare e risolvere i problemi.
I dati CrUX sono più rappresentativi del rendimento reale della tua pagina, ma conoscere i punteggi CrUX difficilmente ti aiuterà a capire come migliorare il rendimento.
Lighthouse, invece, identificherà i problemi e fornirà suggerimenti specifici su come migliorare. Tuttavia, Lighthouse fornirà suggerimenti solo per i problemi di prestazioni che rileva durante il tempo di caricamento della pagina. Non rileva problemi che si manifestano solo a seguito dell'interazione dell'utente, ad esempio lo scorrimento o il 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 spiega in dettaglio quali API puoi utilizzare per raccogliere ulteriori informazioni di debug per ciascuna delle attuali metriche di Core Web Vitals e ti fornisce idee su come acquisire questi dati nel tuo strumento di analisi esistente.
API per l'attribuzione e il debug
Cumulative Layout Shift (CLS)
Tra tutte le metriche di Core Web Vitals, CLS è forse quella per cui la raccolta di informazioni di debug sul campo è più importante. La metrica CLS viene misurata per tutta la durata della pagina, quindi il modo in cui un utente interagisce con la pagina, ad esempio quanto scorre, su cosa fa clic e così via, può influire in modo significativo sulla presenza di variazioni del layout e sugli elementi che cambiano.
Considera il seguente report di PageSpeed Insights:
Il valore riportato per CLS dal lab (Lighthouse) rispetto a CLS dal campo (dati CrUX) è molto diverso e questo ha senso se si considera che la pagina potrebbe avere molti contenuti interattivi che non vengono utilizzati durante il test in Lighthouse.
Anche se comprendi che l'interazione dell'utente influisce sui dati dei campi, devi comunque sapere quali elementi della pagina si spostano per ottenere un punteggio di 0,28 al 75° percentile. L'interfaccia LayoutShiftAttribution lo rende possibile.
Ottenere l'attribuzione della variazione del layout
L'interfaccia LayoutShiftAttribution
è esposta in ogni voce layout-shift emessa dall'API Layout Instability.
Per una spiegazione dettagliata di entrambe le interfacce, consulta Debug degli spostamenti del layout. Ai fini di questo post, la cosa principale che devi sapere è che, in qualità di sviluppatore, puoi osservare ogni spostamento del layout che si verifica nella pagina, nonché gli elementi che si spostano.
Ecco un codice di esempio che registra ogni variazione del layout, nonché gli elementi che hanno subito lo spostamento:
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 allo strumento di analisi per ogni singolo spostamento del layout che si verifica. Tuttavia, monitorando tutti gli spostamenti, puoi tenere traccia di quelli peggiori e segnalare solo le informazioni relative a questi.
L'obiettivo non è identificare e correggere ogni singolo spostamento del layout che si verifica per ogni utente, ma identificare gli spostamenti che interessano il maggior numero di utenti e che quindi contribuiscono maggiormente al CLS della pagina al 75° percentile.
Inoltre, non è necessario calcolare l'elemento di origine più grande ogni volta che si verifica uno spostamento, ma solo quando si è pronti a inviare il valore CLS allo strumento di analisi.
Il seguente codice accetta un elenco di voci layout-shift che hanno contribuito
alla metrica CLS e restituisce l'elemento di origine più grande dallo spostamento 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ù grande che contribuisce al cambiamento più grande, puoi segnalarlo allo strumento di analisi.
L'elemento che contribuisce maggiormente al CLS per una determinata pagina varia probabilmente da utente a utente, ma se aggreghi questi elementi per tutti gli utenti, potrai generare un elenco di elementi che cambiano e che interessano il maggior numero di utenti.
Dopo aver identificato e risolto la causa principale degli spostamenti di questi elementi, il codice Analytics inizierà a segnalare spostamenti più piccoli come i "peggiori" spostamenti per le tue pagine. Alla fine, tutti gli spostamenti segnalati saranno così piccoli che le tue pagine rientreranno ampiamente nella soglia "buona" di 0,1.
Altri metadati che potrebbero essere utili da acquisire insieme all'elemento di origine dello spostamento più grande sono:
- L'ora dello spostamento più grande
- Il percorso dell'URL al momento del cambiamento più grande (per i siti che aggiornano dinamicamente l'URL, come le applicazioni a pagina singola).
Largest Contentful Paint (LCP)
Per eseguire il debug della metrica LCP sul campo, le informazioni principali di cui hai bisogno sono l'elemento specifico che era l'elemento più grande (l'elemento candidato LCP) per quel particolare caricamento pagina.
Tieni presente che è del tutto possibile, anzi è piuttosto 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 comporta layout di pagina diversi e quindi elementi diversi visibili all'interno dell'area visibile.
- Gli utenti non caricano sempre le pagine scorrendo fino in cima. 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 della pagina.
- I contenuti potrebbero essere personalizzati per l'utente corrente, pertanto l'elemento candidato LCP potrebbe variare notevolmente da utente a utente.
Ciò significa che non puoi 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.
Identifica l'elemento candidato LCP
Per determinare l'elemento candidato LCP in JavaScript, puoi utilizzare l'API Largest Contentful Paint, la stessa API che utilizzi per determinare il valore temporale LCP.
Quando osservi le voci largest-contentful-paint, puoi determinare l'elemento candidato LCP corrente esaminando 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 gli elementi più importanti da ottimizzare per primi.
Oltre all'elemento candidato LCP, può essere utile misurare anche i tempi delle sottoparti 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 nel campo per INP sono:
- Con quale elemento è stata eseguita l'interazione
- Il tipo di interazione
- Quando si è verificata l'interazione
Una delle principali cause di interazioni lente è un thread principale bloccato, il che può essere comune durante il caricamento di JavaScript. Sapere se la maggior parte delle interazioni lente si verifica 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 tutti i listener di eventi registrati, nonché il tempo necessario per disegnare il frame successivo dopo l'esecuzione di tutti i listener di eventi. Ciò significa che per INP è molto utile sapere quali elementi target tendono a generare interazioni lente e di che tipo sono queste interazioni.
Il seguente codice registra l'elemento di destinazione 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é la 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 che invii al tuo strumento di analisi.
A partire dalla versione 3, la libreria JavaScript web-vitals include una compilazione dell'attribuzione che mostra tutte queste informazioni, nonché alcuni indicatori aggiuntivi.
Il seguente esempio di codice mostra come impostare un parametro evento (o una dimensione personalizzata) aggiuntivo contenente una stringa di debug utile per identificare la causa principale dei problemi di rendimento.
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 di INP, potresti voler raccogliere l'elemento con cui viene interagito, il tipo di interazione, l'ora, loadState, le fasi di interazione e altro ancora (ad esempio i dati Long Animation Frame).
La build di attribuzione web-vitals espone ulteriori informazioni sull'attribuzione,
come mostrato nel seguente esempio 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 l'elenco completo dei segnali di debug esposti, consulta la documentazione sull'attribuzione delle metriche Web Vitals.
Generare report e visualizzare i dati
Una volta iniziata la raccolta delle informazioni di debug insieme ai valori delle metriche, il passaggio successivo consiste nell'aggregare i dati di tutti gli utenti per iniziare a cercare pattern e tendenze.
Come accennato in precedenza, non è necessario risolvere ogni singolo problema riscontrato dagli utenti. Inizialmente, è meglio concentrarsi sui problemi che interessano il maggior numero di utenti, che dovrebbero essere anche quelli che hanno l'impatto negativo maggiore sui punteggi dei 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 delineare i modi specifici in cui puoi utilizzare le API per il rendimento esistenti e la libreria web-vitals per ottenere informazioni di debug che ti aiutino a diagnosticare il rendimento in base alle visite degli utenti reali sul campo. Sebbene questa guida si concentri sui Core Web Vitals, i concetti si applicano anche al debug di qualsiasi metrica sul rendimento misurabile in JavaScript.
Se sei un fornitore di analisi e vuoi migliorare i tuoi prodotti e fornire maggiori informazioni di debug ai tuoi utenti, prendi in considerazione alcune delle tecniche descritte qui, ma non limitarti solo alle idee presentate qui. Questo post è pensato per essere applicabile in generale a tutti gli strumenti di analisi; tuttavia, i singoli strumenti di analisi probabilmente possono (e devono) acquisire e segnalare ancora più informazioni di debug.
Infine, se ritieni che ci siano 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.