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 riportati da strumenti quali PageSpeed Insights e Search Console provengono dai dati CrUX.
Mentre gli strumenti sul campo offrono dati più accurati, che rappresentano effettivamente l'esperienza reale degli utenti, gli strumenti di laboratorio sono spesso più efficaci nell'aiutarti a 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 sulle prestazioni da utenti reali sul campo?
Questo post spiegherà nel dettaglio quali API puoi utilizzare per raccogliere ulteriori informazioni di debug per ciascuna delle attuali metriche di Core Web Vitals e ti fornirà idee su come acquisire questi dati nel tuo 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. La metrica CLS viene misurata lungo l'intera durata della pagina, quindi il modo in cui un utente interagisce con la pagina (quanto scorre la pagina, cosa fa clic e così via) può avere un impatto significativo sull'eventuale presenza di variazioni del layout e di elementi in continua evoluzione.
Considera il seguente report di PageSpeed Insights:
Il valore riportato per la metrica CLS dal lab (Lighthouse) rispetto al valore CLS del 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.
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 Debug delle variazioni del 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 esempio di codice che registra ogni variazione del layout e gli elementi interessati:
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 spostamento, ma devi farlo solo quando è tutto pronto per inviare il valore CLS allo strumento di analisi.
Il seguente codice prende un elenco di layout-shift voci che hanno contribuito
alla 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 alla CLS per una determinata pagina varierà probabilmente da utente a utente, ma se aggreghi questi elementi tra tutti gli utenti, sarai in grado di generare un elenco di elementi in continua evoluzione 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, tutte le variazioni riportate saranno sufficientemente ridotte da far rientrare le pagine entro la soglia "buona" di 0,1.
Ecco alcuni altri metadati che potrebbero essere utili da acquisire insieme all'elemento di origine della variazione più grande:
- 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 genera layout di pagina diversi e, di conseguenza, elementi diversi nell'area visibile.
- Gli utenti non sempre caricano le pagine scorrendo fino in cima. Spesso i link contengono identificatori di frammenti o persino frammenti di testo, il che significa che le tue pagine potrebbero essere caricate e visualizzate in qualsiasi posizione di scorrimento della pagina.
- 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 che utilizzi per determinare il valore temporale 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 al tuo strumento di analisi insieme al valore della metrica. Come per CLS, questo ti aiuterà a identificare gli elementi più importanti da ottimizzare per primi.
Oltre all'elemento candidato LCP, può essere utile anche misurare i tempi parziali 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 cause principali delle interazioni lente è il blocco del thread principale, che può essere comune durante il caricamento di JavaScript. Sapere se le interazioni più lente si verificano 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 qualsiasi listener di eventi registrato, nonché il tempo necessario per visualizzare 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 quali tipi di interazioni 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 sia la voce INP, in quanto questa logica è maggiormente coinvolta. Tuttavia, la sezione seguente spiega come ottenere queste informazioni utilizzando la libreria JavaScript web-vitals.
Utilizzo con la libreria JavaScript Webvitals
Le sezioni precedenti forniscono 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 creazione di attribuzione che mostra tutte queste informazioni e anche 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);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Questo codice è specifico per Google Analytics, ma l'idea generale dovrebbe essere applicata anche ad altri strumenti di analisi.
Inoltre, questo codice mostra 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 interagisci, il tipo di interazione, l'ora, il loadState, le fasi di interazione e altro ancora (ad esempio 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);
Consulta la documentazione sull'attribuzione delle vitali web per l'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 pattern e tendenze.
Come accennato in precedenza, non devi necessariamente risolvere 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 i problemi che hanno l'impatto negativo maggiore sui 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 delineare i modi specifici in cui puoi utilizzare le
API per le prestazioni esistenti e la libreria web-vitals per ottenere informazioni di debug
al fine di diagnosticare il rendimento in base alle visite reali degli utenti sul campo. Questa guida è incentrata sui Core Web Vitals, ma i concetti si applicano anche al debug di 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 Report Web Vitals può essere un buon punto di partenza, perché supporta già la generazione di report di debug delle informazioni 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 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.