Come misurare i Segnali web con il tuo attuale strumento di analisi.
Avere la possibilità di misurare e generare report sulle prestazioni reali delle tue pagine è fondamentale per diagnosticare e migliorare le prestazioni nel tempo. Senza i dati sul campo, è impossibile sapere con certezza se le modifiche apportate al sito stanno effettivamente ottenendo i risultati desiderati.
Molti provider di analisi noti per il Real User Monitoring (RUM) supportano già le metriche Segnali web essenziali nei propri strumenti (nonché in molti altri Segnali web). Se attualmente utilizzi uno di questi strumenti di analisi del RUM, sei in grado di valutare in che misura le pagine del tuo sito soddisfano le soglie consigliate per i Segnali web essenziali e prevenire le regressioni in futuro.
Consigliamo di utilizzare uno strumento di analisi che supporti le metriche di Segnali web essenziali, ma se lo strumento di analisi in uso non le supporta, non è necessario effettuare il passaggio. 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 di Segnali web essenziali 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 di terze parti o interno. Può anche fungere da guida per i fornitori di analisi che vogliono aggiungere al loro servizio il supporto di Core Web Vitals.
Utilizzare metriche o eventi personalizzati
Come accennato in precedenza, la maggior parte degli strumenti di analisi consente di misurare dati personalizzati. Se il tuo strumento di analisi supporta questa funzionalità, dovresti essere in grado di misurare ciascuna delle metriche di Core Web Vitals utilizzando questo meccanismo.
La misurazione di eventi o metriche personalizzate in uno strumento di analisi è generalmente una procedura suddivisa in tre passaggi:
- Definisci o registra la metrica personalizzata nell'amministratore dello strumento (se necessario). Nota: non tutti i fornitori di analisi richiedono che le metriche personalizzate siano definite in anticipo.
- Calcola il valore della metrica nel codice JavaScript frontend.
- Invia il valore della metrica al backend di Analytics, assicurandoti che il nome o l'ID corrisponda a quanto definito nel passaggio 1 (di nuovo, se necessario).
Per i passaggi 1 e 3, consulta la documentazione dello strumento di analisi per le istruzioni. Per il passaggio 2, puoi utilizzare la libreria JavaScript web-vitals per calcolare il valore di ciascuna delle metriche di 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, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Evita le medie
Si è tentati di sommare un intervallo di valori per una metrica relativa alle prestazioni calcolando una media. Le medie sembrano comode a prima vista, in quanto sono un chiaro riepilogo di una grande quantità di dati, ma dovresti resistere alla tentazione di farvi affidamento per interpretare il rendimento delle pagine.
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 trovarsi su reti o dispositivi estremamente lenti per raggiungere l'intervallo massimo di valori, ma non considerare un numero sufficiente di sessioni utente per influire sulla media, in modo da suggerire la presenza di un problema.
Se possibile, affidati ai percentili anziché alle medie. I percentili in una distribuzione di una determinata metrica di rendimento descrivono meglio l'intera gamma di esperienze utente per il tuo sito web. Ciò ti consente di concentrarti su sottoinsiemi di esperienze effettive, in modo da ottenere più informazioni di quanto non sia mai stato possibile ottenere con un singolo valore.
Assicurati di poter segnalare una distribuzione
Dopo aver calcolato i valori per ciascuna delle metriche di Segnali web essenziali e averli inviati al tuo servizio di analisi utilizzando una metrica o un evento personalizzato, il passaggio successivo consiste nella creazione di un report o di una dashboard che mostri i valori raccolti.
Per assicurarti di raggiungere le soglie consigliate per i Segnali web essenziali, il tuo report dovrà visualizzare il valore di ogni metrica al 75° percentile.
Se il tuo strumento di analisi non offre la generazione di report sui quantili come funzionalità integrata, probabilmente puoi comunque ottenere questi dati manualmente generando un report che elenchi ogni valore di metrica in ordine crescente. Una volta generato il report, il risultato, pari al 75% dell'elenco completo e ordinato di tutti i valori nel report, sarà il 75° percentile per quella metrica, indipendentemente dal modo in cui segmenti i dati (per tipo di dispositivo, tipo di connessione, paese e così via).
Se il tuo strumento di analisi non fornisce per impostazione predefinita granularità dei report a livello di metrica, probabilmente puoi ottenere lo stesso risultato se il tuo strumento di analisi supporta dimensioni personalizzate. Se imposti un valore della dimensione personalizzata univoco per ogni singola istanza della metrica monitorata, dovresti essere in grado di generare un report suddiviso per singole istanze di metrica, se includi la dimensione personalizzata nella configurazione del report. Poiché ogni istanza avrà un valore di dimensione univoco, non verrà eseguito alcun raggruppamento.
Il report Web Vitals è un esempio di questa tecnica che utilizza Google Analytics. Il codice del report è open source, quindi gli sviluppatori possono utilizzarlo come esempio delle tecniche descritte in questa sezione.
Invia i dati al momento giusto
Alcune metriche sulle prestazioni possono essere calcolate al termine del caricamento della pagina, mentre altre (come CLS) considerano l'intera durata della pagina e sono definitive solo dopo l'inizio dell'unload della pagina.
Tuttavia, questo può rappresentare un problema, poiché entrambi gli eventi beforeunload e unload
non sono affidabili (soprattutto sui dispositivi mobili) e il loro utilizzo non
è consigliato
(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 qualsiasi valore attuale della metrica durante l'evento visibilitychange, ogni volta che lo stato di visibilità della pagina diventa hidden. Questo perché, una volta che lo stato di visibilità della pagina diventa hidden, non vi è alcuna garanzia che qualsiasi script nella pagina possa essere eseguito di nuovo. Ciò è particolarmente vero nei sistemi operativi mobile in cui l'app browser stessa può essere chiusa senza attivare i callback di pagina.
Tieni presente che in genere i sistemi operativi per dispositivi mobili attivano l'evento visibilitychange quando cambi scheda, cambi app o chiudi l'app del browser stessa.
Attivano anche l'evento visibilitychange quando si chiude una scheda o si accede a una nuova pagina. Questo rende l'evento visibilitychange molto più affidabile degli
eventi unload o beforeunload.
Monitora le prestazioni nel tempo
Dopo aver aggiornato l'implementazione dell'analisi per monitorare e generare report sulle metriche di Segnali web essenziali, il passaggio successivo consiste nel monitorare in che modo le modifiche al sito influiscono sulle prestazioni nel tempo.
Versione delle modifiche
Un approccio ingenuo (e infine inaffidabile) al monitoraggio delle modifiche consiste nell'eseguire il deployment delle modifiche in produzione, quindi presupporre che tutte le metriche ricevute dopo la data di deployment corrispondano al nuovo sito e che tutte le metriche ricevute prima di questa data corrispondano al sito precedente. Tuttavia, qualsiasi numero di fattori (tra cui la memorizzazione nella cache a livello di HTTP, service worker o CDN) può impedirne il funzionamento.
Un approccio migliore consiste nel creare una versione univoca per ogni modifica di cui è stato eseguito il deployment e nel monitorare la versione nello strumento di analisi. Gran parte degli strumenti di analisi supporta l'impostazione di una versione. In caso contrario, puoi creare una dimensione personalizzata e impostarla sulla versione di cui hai eseguito il deployment.
Esecuzione di esperimenti
Puoi andare oltre il controllo delle versioni monitorando più versioni (o esperimenti) contemporaneamente.
Utilizza questa funzionalità se lo strumento di analisi consente di definire gruppi sperimentali. In alternativa, puoi utilizzare le dimensioni personalizzate per assicurarti che i valori delle metriche possano essere associati a un determinato gruppo sperimentale nei report.
Dopo aver eseguito esperimenti in Analytics, puoi implementare una modifica sperimentale per un sottoinsieme di utenti e confrontare il relativo rendimento con quello degli utenti nel gruppo di controllo. Quando hai la certezza che una modifica migliora effettivamente le prestazioni, puoi implementarla per tutti gli utenti.
Assicurati che la misurazione non influisca sul rendimento
Quando misuri le prestazioni degli utenti reali, è assolutamente fondamentale che qualsiasi codice per la misurazione del rendimento che esegui non influisca negativamente sul rendimento della tua pagina. Se così fosse, qualsiasi conclusione che tenti di trarre sul modo in cui le prestazioni influiscono sulla tua attività sarà inaffidabile, in quanto non saprai mai se la presenza del codice di analisi stesso sta avendo il maggiore impatto negativo.
Segui sempre questi principi quando esegui il deployment del codice di analisi RUM sul tuo sito di produzione:
Rimanda l'analisi
Il codice di Analytics deve essere sempre caricato in modo asincrono e non bloccante e di solito deve essere caricato per ultimo. Se carichi il codice di analisi in modo bloccante, questo può influire negativamente sulla LCP.
Tutte le API utilizzate per misurare le metriche di Segnali web essenziali sono state progettate specificamente per supportare il caricamento degli script asincrono e differito (tramite il flag buffered), quindi non c'è fretta di caricare gli script in anticipo.
Se stai misurando una metrica che non può essere calcolata in un secondo momento nella sequenza temporale del caricamento della pagina, devi incorporare solo il codice che deve essere eseguito all'inizio nel <head> del documento (quindi non si tratta di una richiesta di blocco della visualizzazione) e rimandare il resto. Non caricare tutti i dati di analisi in anticipo solo perché è richiesto da una sola metrica.
Non creare attività lunghe
Il codice di analisi spesso viene eseguito in risposta all'input dell'utente, ma se il codice di analisi esegue molte misurazioni DOM o utilizza altre API che utilizzano molte risorse di 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 di questo file può bloccare il thread principale e influire negativamente su First Input Delay (FID) o Interaction to Next Paint (INP).
Usa API che non bloccano
API come
sendBeacon()
e
requestIdleCallback()
sono specificamente progettate per eseguire attività non critiche in modo da non
bloccare quelle degli utenti.
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 ciò che ti serve
Il browser mostra molti dati sul rendimento, ma il semplice fatto che i dati siano disponibili non significa necessariamente che li registri e li inviino ai server di analisi.
Ad esempio, l'API Resource Timing fornisce dati di tempo dettagliati per ogni singola risorsa caricata nella tua pagina. Tuttavia, è improbabile che tutti questi dati siano necessariamente o utili per migliorare le prestazioni del carico delle risorse.
In breve, non basta monitorare i dati perché sono presenti, ma assicurati che vengano utilizzati prima di consumare risorse per il monitoraggio.