Come misurare Web Vitals con il tuo attuale strumento di analisi.
Avere la possibilità di misurare e generare report sul rendimento reale del tuo pagine è fondamentale per diagnosticare e migliorare le prestazioni nel tempo. Senza campo i tuoi dati, è impossibile sapere con certezza se le modifiche che apporti al tuo sito stanno effettivamente raggiungendo i risultati desiderati.
Molti modelli di Real User Monitoring (RUM) supporta già le metriche Core Web Vitals nei propri (nonché tanti altri Web Vitals). Se stai utilizzando uno di questi strumenti di analisi RUM, sei in forma per Valuta in che misura le pagine del tuo sito soddisfano i Core Web Vitals consigliati soglie ed evita le regressioni in futuro.
Consigliamo di utilizzare uno strumento di analisi che supporti Core Web Vitals metriche, se lo strumento di analisi che utilizzi non le supporta, non necessariamente il passaggio. Quasi tutti gli strumenti di analisi offrono un modo definiscono e misurano metriche o eventi, ovvero è probabile che possa usare il tuo attuale provider di analisi per misurare i Core Web Vitals metriche e le aggiunge alle dashboard e ai report di analisi esistenti.
Questa guida illustra le best practice per la misurazione delle metriche di Core Web Vitals (o di eventuali metriche personalizzate) con uno strumento di analisi di terze parti o interno. 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 già detto, la maggior parte degli strumenti di analisi consente di misurare i dati personalizzati. Se le tue di analisi supporta questo aspetto, dovresti essere in grado di misurare tutti i dati Metriche vitals che utilizzano questo meccanismo.
La misurazione di metriche o eventi personalizzati in uno strumento di analisi è in genere in tre fasi:
- Definisci o registrati la metrica personalizzata nell'amministratore del tuo strumento (se necessario). (Nota: non tutte i provider di analisi richiedono che le metriche personalizzate siano definite in anticipo.)
- Calcola il valore della metrica nel codice JavaScript del frontend.
- Invia il valore della metrica al backend di analisi, assicurandoti che il nome o l'ID corrisponde a quanto definito al passaggio 1 (di nuovo, se necessario).
Per i passaggi 1 e 3, puoi fare riferimento alla documentazione dello strumento di analisi per istruzioni. Per il passaggio 2 puoi utilizzare libreria JavaScript web-vitals per calcolare il valore di ciascuna delle metriche del Core Web Vitals.
Il seguente esempio di codice mostra quanto sia facile monitorare queste metriche in 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);
Evita medie
Si può avere la tentazione di sommare un intervallo di valori di una metrica di rendimento in calcolare una media. I valori medi a prima vista sembrano comodi perché sono un riassunto ordinato di una grande quantità di dati, ma è bene resistere alla voglia di affidarsi per interpretare il rendimento della pagina.
Le medie sono problematiche perché non rappresentano la sessione di nessun singolo utente. Valori anomali in entrambi gli intervalli della distribuzione può alterare la media in modi fuorvianti.
Ad esempio, un piccolo gruppo di utenti potrebbe trovarsi su reti o dispositivi estremamente lenti che rientrano nell'intervallo massimo di valori, ma che non considerano un numero sufficiente di utenti sessioni in modo da influire sulla media in modo da suggerire la presenza di un problema.
Se possibile, utilizza i percentili anziché le medie. Percentili attraverso un distribuzione per una determinata metrica di rendimento descrivere meglio l'intera gamma esperienze utente del tuo sito web. Ciò ti consente di concentrarti su sottoinsiemi esperienze effettive, che ti forniranno più informazioni di quanto non sia mai stato un singolo valore è possibile.
Assicurati di poter segnalare una distribuzione
Dopo aver calcolato i valori di ciascuna delle metriche Core Web Vitals e inviato al tuo servizio di analisi utilizzando una metrica o un evento personalizzato, il passaggio successivo per creare un report o una dashboard che mostri i valori raccolti.
Per assicurarti di soddisfare i Core Web Vitals consigliati soglie, avrai bisogno del tuo report per visualizzare il valore di ogni metrica al 75° percentile.
Se il tuo strumento di analisi non offre report sui quantili come funzionalità integrata, probabilmente puoi comunque ottenere questi dati manualmente generando un report che elenchi ogni valore di metrica ordinato in ordine crescente. Una volta generato questo report, risultato che corrisponde al 75% dell'intero elenco ordinato di tutti i valori in il report sarà il 75° percentile per quella metrica e questo sarà il a prescindere da come segmenti i dati (per tipo di dispositivo, tipo di connessione, paese ecc.).
Se lo strumento di analisi non fornisce granularità dei report a livello di metrica tramite per impostazione predefinita, probabilmente puoi ottenere lo stesso risultato se il tuo strumento di analisi supporta dati personalizzati dimensioni. Impostando un valore di dimensione personalizzata unico per ogni singola istanza di metrica monitorata dovresti essere in grado di generare un report, suddiviso per singola 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 Esempio di questa tecnica che utilizza Google Analytics. Il codice per è open source, in modo che gli sviluppatori possano farvi riferimento come esempio delle tecniche descritte in questo .
Invia i tuoi dati al momento giusto
Alcune metriche sul rendimento possono essere calcolate al termine del caricamento della pagina mentre altre (come CLS) considerano l'intera durata della pagina e sono solo una volta avviato l'unload della pagina.
Questo può essere problematico, tuttavia, poiché sia beforeunload sia unload
eventi non sono affidabili (soprattutto sui dispositivi mobili) e il loro uso non è
consigliato
(poiché possono impedire a una pagina di essere idonea per la pagina
Cache).
Per le metriche che monitorano l'intera durata di una pagina, è preferibile inviare qualsiasi
il valore attuale della metrica si trova durante l'evento visibilitychange, ogni volta che
lo stato di visibilità della pagina diventa hidden. Il motivo è che, una volta che il sito
lo stato di visibilità cambia in hidden, non c'è alcuna garanzia che nessuno script
quella pagina potrà essere pubblicata di nuovo. Ciò è particolarmente vero per il funzionamento sui dispositivi mobili
sistemi in cui l'app del browser può essere chiusa senza callback di pagina
essere licenziati.
Tieni presente che in genere i sistemi operativi per dispositivi mobili attivano visibilitychange
evento quando si cambia scheda, si cambia app o si chiude l'app del browser.
Attivano l'evento visibilitychange anche alla chiusura di una scheda o alla navigazione verso
una nuova pagina. Questo rende l'evento visibilitychange molto più affidabile dell'evento
Eventi unload o beforeunload.
Monitorare il rendimento nel tempo
Una volta aggiornata l'implementazione dell'analisi per monitorare e generare report le metriche Core Web Vitals, il passaggio successivo consiste nel monitorare le modifiche al sito influisce sulle prestazioni nel tempo.
Versione delle modifiche
Un approccio ingenuo (e sostanzialmente inaffidabile) al monitoraggio delle modifiche consiste nell'implementare modifiche in produzione, per poi presupporre che tutte le metriche ricevute dopo corrispondono al nuovo sito e a tutte le metriche ricevute prima del giorno la data di deployment del sito corrisponda a quella del sito precedente. Tuttavia, ci sono vari fattori (compresa la memorizzazione nella cache a livello di HTTP, service worker o CDN) può impedire dall'attività lavorativa.
Un approccio molto migliore consiste nel creare una versione unica per ogni modifica di cui viene eseguito il deployment e poi monitorarla nello strumento di analisi. La maggior parte degli strumenti di analisi supporta impostare una versione. In caso contrario, puoi creare una dimensione personalizzata e impostare alla versione di cui hai eseguito il deployment.
Esecuzione di esperimenti
Puoi portare il controllo delle versioni a un livello superiore monitorando più versioni (o esperimenti) contemporaneamente.
Se lo strumento di analisi ti consente di definire gruppi sperimentali, utilizza questa funzionalità. Altrimenti, puoi usare le dimensioni personalizzate per assicurarti che ogni valore delle metriche può essere associato a un determinato gruppo sperimentale nei report.
Con la sperimentazione in Analytics, puoi implementare un modifica sperimentale con un sottoinsieme dei tuoi utenti e confronta il rendimento che modificano il rendimento degli utenti nel gruppo di controllo. Dopo aver ottenuto con certezza che una modifica migliora effettivamente il rendimento, la puoi implementare tutti gli utenti.
Assicurati che la misurazione non influisca sul rendimento
Quando misuri il rendimento degli utenti reali, è assolutamente fondamentale che qualsiasi il codice per la misurazione delle prestazioni in esecuzione non influisce negativamente sulla il rendimento della tua pagina. Se sì, le conclusioni che tenti di trarre sul modo in cui il rendimento influisce sulla tua attività sia inaffidabile, come non sapere mai se la presenza del codice di analisi stesso sta avendo il più un impatto negativo.
Segui sempre questi principi quando esegui il deployment del codice per l'analisi RUM sul tuo sito di produzione:
Rimanda l'analisi
Il codice di Analytics deve essere sempre caricato in modo asincrono e non bloccante. di solito dovrebbe essere caricato per ultimo. Se carichi il codice di analisi in una blocco, può influire negativamente su LCP.
Tutte le API utilizzate per misurare le metriche di Core Web Vitals erano specificamente
progettato per supportare il caricamento di script asincrono e differito (tramite
buffered), quindi
non c'è fretta di caricare gli script in anticipo.
Nel caso in cui tu stia misurando una metrica che non può essere calcolata in un secondo momento
pagina, devi incorporare solo il codice da eseguire in anticipo
nella <head> del documento (quindi non si tratta di un blocco
richiesta) e rinviare il resto. Non caricare tutti i tuoi
l'analisi anticipata solo perché una sola metrica lo richiede.
Non creare attività lunghe
Il codice di Analytics viene spesso eseguito in risposta all'input degli utenti, ma se il codice di analisi sta conducendo molte misurazioni DOM o utilizzando altre API ad alta intensità di processore il codice di Analytics stesso può causare una scarsa reattività dell'input. Inoltre, se Il file JavaScript contenente il codice di analisi sia di grandi dimensioni ed esegue questo file possono bloccare il thread principale e influire negativamente sull'interazione con Next Paint (INP) di una pagina.
Usa API che non bloccano la migrazione
API come
sendBeacon()
e
requestIdleCallback()
sono progettati specificamente per l'esecuzione di attività non critiche in modo da
bloccare attività critiche per l'utente.
Queste API sono ottimi strumenti da usare 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
periodi di inattività.
Non monitorare più del necessario
Il browser espone molti dati sul rendimento, ma solo perché i dati sono disponibile non significa necessariamente che sia necessario registrarlo e inviarlo al tuo i server di analisi.
Ad esempio, l'API Resource Timing, fornisce dati temporali dettagliati per ogni singola risorsa caricata sulla pagina. Tuttavia, è improbabile che tutti questi dati siano necessariamente o utili in migliorando le prestazioni del carico di risorse.
In breve, non limitarti a monitorare i dati perché si trovano già; assicurati che vengano utilizzati prima di utilizzare le risorse per monitorarla.