Come misurare le metriche Web Vitals con lo strumento di analisi attuale.
Avere la possibilità di misurare e generare report sulle prestazioni reali delle tue pagine è fondamentale per diagnosticare e migliorare le prestazioni nel tempo. Senza dati di campo, è impossibile sapere con certezza se le modifiche apportate al sito stanno effettivamente raggiungendo i risultati desiderati.
Molti fornitori di analisi di monitoraggio in tempo reale (RUM) di uso comune supportano già le metriche Core Web Vitals nei propri strumenti (nonché molti altri Web Vitals). Se al momento utilizzi uno di questi strumenti di analisi RUM, hai a disposizione tutto il necessario per valutare il grado di conformità delle pagine del tuo sito alle soglie consigliate per i Core Web Vitals e per prevenire le regressioni in futuro.
Sebbene consigliamo di utilizzare uno strumento di analisi che supporti le metriche Core Web Vitals, se lo strumento di analisi che utilizzi al momento non le supporta, non è necessariamente necessario passare a un altro. Quasi tutti gli strumenti di analisi offrono un modo per definire e misurare metriche o eventi personalizzati, il che significa che probabilmente puoi utilizzare il tuo attuale provider di analisi per misurare le metriche Core Web Vitals e aggiungerle alle dashboard e ai report di analisi esistenti.
Questa guida illustra le best practice per misurare le metriche di Core Web Vitals (o qualsiasi metrica personalizzata) con uno strumento di analisi interno o di terze parti. Può anche fungere da guida per i fornitori di soluzioni di analisi che vogliono aggiungere il supporto di Core Web Vitals al proprio servizio.
Utilizzare metriche o eventi personalizzati
Come accennato in precedenza, la maggior parte degli strumenti di analisi ti consente di misurare i dati personalizzati. Se lo strumento di analisi supporta questa funzionalità, dovresti essere in grado di misurare ciascuna delle metriche Core Web Vitals utilizzando questo meccanismo.
La misurazione di metriche o eventi personalizzati in uno strumento di analisi in genere prevede tre passaggi:
- Definisci o registra la metrica personalizzata nella pagina di amministrazione dello strumento (se necessario). (Nota: non tutti i fornitori di servizi di analisi richiedono la definizione anticipata delle metriche personalizzate.)
- Calcola il valore della metrica nel codice JavaScript frontend.
- Invia il valore della metrica al backend di analisi, assicurandoti che il nome o l'ID sia uguale a quello definito nel passaggio 1 (di nuovo, se necessario).
Per le istruzioni, consulta la documentazione del tuo strumento di analisi. Per il passaggio 2, puoi utilizzare la libreria JavaScript web-vitals per calcolare il valore di ciascuna delle metriche Core Web Vitals.
Il seguente esempio di codice mostra quanto può essere facile monitorare queste metriche nel codice e inviarle a un servizio di analisi.
import {onCLS, onINP, onLCP} from 'web-vitals';
function sendToAnalytics({name, value, id}) {
const body = JSON.stringify({name, value, id});
// Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
(navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
fetch('/analytics', {body, method: 'POST', keepalive: true});
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
Evitare le medie
È facile essere tentati di sommare un intervallo di valori per una metrica sul rendimento calcolandovi la media. Le medie sembrano convenienti a prima vista, in quanto rappresentano un riepilogo ordinato di una grande quantità di dati, ma devi resistere all'impulso di fare affidamento su di esse per interpretare il rendimento della pagina.
Le medie sono problematiche perché non rappresentano la sessione di un singolo utente. I valori anomali in entrambi gli intervalli di distribuzione possono alterare la media in modi fuorvianti.
Ad esempio, un piccolo gruppo di utenti potrebbe utilizzare reti o dispositivi estremamente lenti che si avvicinano all'intervallo massimo di valori, ma non generano un numero sufficiente di sessioni dell'utente da influire sulla media in modo da suggerire che esiste un problema.
Se possibile, utilizza i percentile anziché le medie. I percentile in una distribuzione per una determinata metrica sul rendimento descrivono meglio l'intera gamma di esperienze utente per il tuo sito web. In questo modo, puoi concentrarti su sottoinsiemi di esperienze effettive, che ti forniranno più informazioni di quanto potrebbe fare un singolo valore.
Assicurati di poter segnalare una distribuzione
Dopo aver calcolato i valori per ciascuna delle metriche Core Web Vitals e averli inviati al tuo servizio di analisi utilizzando una metrica o un evento personalizzato, il passaggio successivo consiste nel creare un report o una dashboard che mostri i valori raccolti.
Per assicurarti di soddisfare le soglie consigliate per Segnali web essenziali, il report deve mostrare il valore di ogni metrica al 75° percentile.
Se lo strumento di analisi non offre i report sui quantili come funzionalità integrata, probabilmente puoi comunque ottenere questi dati manualmente generando un report che elenca ogni valore della metrica in ordine crescente. Una volta generato questo report, il risultato che corrisponde al 75% dell'elenco completo e ordinato di tutti i valori nel report sarà il 75° percentile per quella metrica. Questo accade indipendentemente da come segmenti i dati (per tipo di dispositivo, tipo di connessione, paese e così via).
Se lo strumento di analisi non fornisce per impostazione predefinita granularità dei report a livello di metrica, probabilmente puoi ottenere lo stesso risultato se lo strumento di analisi supporta dimensioni personalizzate. Se imposti un valore di dimensione personalizzata univoco per ogni singola istanza della metrica monitorata, dovresti essere in grado di generare un report suddiviso in base alle singole istanze della metrica, se includi la dimensione personalizzata nella configurazione del report. Poiché ogni istanza avrà un valore di dimensione univoco, non verrà generato alcun raggruppamento.
Il report Web Vitals è un esempio di questa tecnica che utilizza Google Analytics. Il codice del report è open source, pertanto gli sviluppatori possono utilizzarlo come esempio delle tecniche descritte in questa sezione.
Invia i dati al momento giusto
Alcune metriche sul rendimento possono essere calcolate al termine del caricamento della pagina, mentre altre (come il CLS) prendono in considerazione l'intera durata della pagina e sono definitive solo al termine del relativo scarico.
Tuttavia, questo può essere problematico, poiché sia gli eventi beforeunload sia unload
non sono affidabili (soprattutto su dispositivi mobili) e il loro utilizzo è sconsigliato
(poiché possono impedire a una pagina di essere idonea per la cache back-forward).
Per le metriche che monitorano l'intera durata di una pagina, è preferibile inviare il valore corrente della metrica durante l'evento visibilitychange, ogni volta che lo stato di visibilità della pagina passa a hidden. Questo perché, quando lo stato di visibilità della pagina diventa hidden, non vi è alcuna garanzia che qualsiasi script in quella pagina possa essere eseguito di nuovo. Questo è particolarmente vero sui sistemi operativi mobile, dove l'app del browser stessa può essere chiusa senza che vengano attivati i callback della pagina.
Tieni presente che i sistemi operativi mobile in genere attivano l'evento visibilitychange
quando si cambia scheda, si cambia app o si chiude l'app del browser stessa.
Inoltre, attivano l'evento visibilitychange quando viene chiusa una scheda o si passa a una nuova pagina. Ciò rende l'evento visibilitychange molto più affidabile degli eventi unload o beforeunload.
Monitora il rendimento nel tempo
Dopo aver aggiornato l'implementazione di Analytics per monitorare e generare report sulle metriche Core Web Vitals, il passaggio successivo consiste nel monitorare l'impatto delle modifiche apportate al sito sul rendimento nel tempo.
Eseguire la versione delle modifiche
Un approccio ingenuo (e alla fine inaffidabile) per monitorare le modifiche consiste nel implementare le modifiche in produzione e poi supporre che tutte le metriche ricevute dopo la data di implementazione corrispondano al nuovo sito e tutte le metriche ricevute prima della data di implementazione corrispondano al vecchio sito. Tuttavia, una serie di fattori (inclusa la memorizzazione nella cache a livello HTTP, di service worker o CDN) può impedire il funzionamento di questa funzionalità.
Un approccio molto migliore è creare una versione univoca per ogni modifica di cui è stato eseguito il deployment e poi monitorarla nello strumento di analisi. La maggior parte degli strumenti di analisi supporta la configurazione di una versione. In caso contrario, puoi creare una dimensione personalizzata e impostarla per la versione di cui è stato eseguito il deployment.
Esecuzione di esperimenti
Puoi fare un ulteriore passo avanti con il controllo delle versioni monitorando contemporaneamente più versioni (o sperimentazioni).
Se lo strumento di analisi ti consente di definire gruppi di esperimenti, utilizza questa funzionalità. In caso contrario, puoi utilizzare le dimensioni personalizzate per assicurarti che ogni valore della metrica possa essere associato a un determinato gruppo sperimentale nei report.
Con la sperimentazione in Analytics, puoi implementare una modifica sperimentale per un sottoinsieme di utenti e confrontare il rendimento di tale modifica con quello degli utenti nel gruppo di controllo. Una volta accertatoti che una modifica migliora effettivamente il rendimento, puoi implementarla per tutti gli utenti.
Assicurati che la misurazione non influisca sul rendimento
Quando misuri il rendimento su utenti reali, è assolutamente fondamentale che il codice di misurazione del rendimento in esecuzione non influisca negativamente sul rendimento della tua pagina. In questo caso, qualsiasi conclusione che tenterai di trarre sul modo in cui il rendimento influisce sulla tua attività non sarà attendibile, in quanto non saprai mai se è la presenza stessa del codice di analisi a avere l'impatto negativo maggiore.
Segui sempre questi principi quando esegui il deployment del codice di analisi RUM sul tuo sito di produzione:
Rimandare le analisi
Il codice di Analytics deve essere sempre caricato in modo asincrono e non bloccante e, in genere, deve essere caricato per ultimo. Se carichi il codice di analisi in modo bloccante, l'LCP potrebbe risentirne.
Tutte le API utilizzate per misurare le metriche di Core Web Vitals sono state progettate appositamente per supportare il caricamento degli script asincroni e differiti (tramite il flag buffered), quindi non c'è bisogno di affrettarsi a caricare gli script in anticipo.
Se stai misurando una metrica che non può essere calcolata più avanti nel tempo di caricamento della pagina, devi inserire in linea solo il codice che deve essere eseguito in anticipo nel <head> del documento (quindi non si tratta di una richiesta che blocca il rendering) e rimandare il resto. Non caricare tutti i dati
in anticipo solo perché una singola metrica lo richiede.
Non creare attività lunghe
Il codice di analisi viene spesso eseguito in risposta all'input dell'utente, ma se il codice di analisi effettua molte misurazioni DOM o utilizza altre API che richiedono un'elevata elaborazione, il codice di analisi stesso può causare una scarsa reattività all'input. Inoltre, se il file JavaScript contenente il codice di analisi è di grandi dimensioni, l'esecuzione del file può bloccare il thread principale e influire negativamente sull'Interaction to Next Paint (INP) di una pagina.
Utilizza API non bloccanti
API come
sendBeacon()
e
requestIdleCallback()
sono progettate specificamente per eseguire attività non critiche in modo da non bloccare le attività critiche per l'utente.
Queste API sono ottimi strumenti da utilizzare in una libreria di analisi RUM.
In generale, tutti i beacon di analisi devono essere inviati utilizzando l'API sendBeacon() (se disponibile) e tutto il codice di misurazione di analisi passiva deve essere eseguito durante i periodi di inattività.
Non monitorare più di quanto necessario
Il browser espone molti dati sul rendimento, ma il semplice fatto che siano disponibili non significa necessariamente che tu debba registrarli e inviarli ai tuoi server di analisi.
Ad esempio, l'API Resource Timing fornisce dati dettagliati sui tempi di ogni singola risorsa caricata nella pagina. Tuttavia, è improbabile che tutti questi dati siano necessariamente o utili per migliorare il rendimento del caricamento delle risorse.
In breve, non limitarti a monitorare i dati perché sono già presenti, assicurati che vengano utilizzati prima di utilizzare le risorse per monitorarli.