Monitoraggio degli utenti reali: comprendere la velocità dei siti web sul campo e in laboratorio

Utenti reali e test di laboratorio

Monitoraggio degli utenti reali (RUM) rileva il funzionamento di un sito web in base alle visite effettive. Una visita effettuata da uno smartphone di vecchia generazione tramite rete mobile può differire notevolmente da una visita da desktop con una connessione veloce. Anche le pagine visitate e le interazioni contribuiscono a delineare il quadro osservato.

A Test di laboratorio analizza invece una chiamata definita in condizioni controllate. Per ogni analisi è possibile specificare il tipo di dispositivo, le condizioni di rete e la procedura di test. Ciò facilita la riproduzione di un’anomalia e la verifica di eventuali modifiche in condizioni comparabili.

I due punti di vista rispondono a domande diverse: i dati raccolti sul campo possono evidenziare che le pagine dei prodotti sui dispositivi mobili spesso vengono visualizzate lentamente. Tuttavia, non dimostrano se la causa sia, ad esempio, l’immagine del prodotto, il percorso di rendering o una risposta lenta del documento. Per individuare la causa sono necessarie ulteriori analisi diagnostiche e ipotesi verificabili.

PageSpeed Insights combina entrambe le prospettive: mette a confronto i dati sul campo disponibili, provenienti dal Chrome User Experience Report, con le analisi di laboratorio basate su Lighthouse. I risultati potrebbero non coincidere, poiché le visite reali si svolgono in condizioni e flussi di utilizzo diversi, mentre il laboratorio prende in esame un caso di test prestabilito.

Il RUM non sostituisce quindi il laboratorio. D’altra parte, un singolo test di laboratorio non è in grado di indicare con quale frequenza un problema si verifichi tra i visitatori reali. Inoltre, prima di una pubblicazione o nel caso di un sito web poco frequentato, potrebbero mancare dati sul campo sufficienti; senza visite reali, infatti, non si ottengono affatto valori di misurazione RUM propri.

Ecco come vengono generati i valori di misura RUM

Una misurazione autonoma richiede tre elementi fondamentali: un sistema di rilevamento nel browser, un ricevitore per i valori trasmessi e un’analisi dei dati. Innanzitutto devi stabilire quali pagine e quali gruppi di visitatori desideri prendere in esame e in che modo proteggere i dati. Solo i singoli valori, raggruppati in modo sensato, costituiscono una base per prendere decisioni.

I browser mettono a disposizione diverse interfacce di performance a tale scopo. Tempi di navigazione descrive i momenti relativi alla navigazione verso il documento, come ad esempio la risposta alla richiesta del documento. Resource Timing fornisce informazioni temporali sulle singole risorse caricate, ad esempio immagini o script. In questo modo è possibile individuare con maggiore precisione le diverse fasi di un processo di caricamento.

A PerformanceObserver monitora i dati relativi alle prestazioni non automatizzati non appena diventano disponibili. Per i Core Web Vitals, la libreria può web-vitals si occupano del calcolo e della segnalazione. La disponibilità delle voci e degli indicatori dipende, tra l’altro, dal browser; pertanto, uno script di monitoraggio non registra automaticamente ogni visita nella sua interezza.

Non tutti i valori vengono generati direttamente durante il caricamento. Per l’INP, ad esempio, è necessaria un’interazione adeguata: chi si limita a leggere una pagina e poi la abbandona potrebbe non fornire alcun valore. Un valore mancante non è quindi né pari a zero né una prova di una risposta rapida.

Un servizio RUM può fornire in un unico pacchetto le funzionalità di raccolta, ricezione e analisi dei dati. Se si utilizza una soluzione sviluppata internamente, è necessario occuparsi anche della gestione operativa, dell’archiviazione e del controllo qualità. Ciò include anche la corretta gestione dei messaggi ripetuti nel corso del ciclo di vita della pagina, anziché contare ogni messaggio come visita indipendente senza verificarlo.

Leggere correttamente i Core Web Vitals

Il sito Vitali Web principali descrivono tre diversi aspetti dell'esperienza utente. Il Largest Contentful Paint (LCP) misura il momento in cui diventa visibile l'elemento di contenuto rilevante più grande. In una pagina di prodotto, ad esempio, può trattarsi di un'immagine di grandi dimensioni del prodotto: se questa appare in ritardo, la pagina potrebbe dare l'impressione di non essere ancora completamente caricata, nonostante la barra di navigazione sia già visibile.

L'Interaction to Next Paint (INP) misura il ritardo tra un'interazione e il successivo aggiornamento visibile. Se un filtro di prodotto reagisce in modo percettibile solo dopo un clic, l’INP può segnalare questo problema. Il Cumulative Layout Shift (CLS), invece, descrive gli spostamenti imprevisti dei contenuti visibili, ad esempio quando un elemento visualizzato successivamente sposta un pulsante.

Ai fini della valutazione in PageSpeed Insights, un LCP fino a 2,5 secondi compresi, un INP fino a 200 millisecondi compresi e un CLS fino a 0,1 compreso sono considerati buoni. Il CLS è un valore senza unità di misura. Le soglie si applicano al rispettivo indicatore e non devono essere confuse con la durata di una singola visita alla pagina.

Un elemento fondamentale per la valutazione sul campo è il 75° percentile (p75): Almeno circa il 75% delle esperienze prese in considerazione non supera il valore in questione. Una buona media, da sola, può invece nascondere il fatto che una parte considerevole delle visite sia lenta. Considera separatamente i dispositivi mobili e i computer desktop, in modo che le differenze tra i gruppi di dispositivi rimangano evidenti.

Il Time to First Byte (TTFB) integra questi indicatori nella ricerca delle cause di una risposta lenta del documento. Tuttavia, questo valore non si riferisce esclusivamente al tempo di elaborazione del server: anche la rete e le altre stazioni coinvolte fino all’arrivo del primo byte di risposta incidono sul risultato. Il Navigation Timing e, se disponibili, i dati relativi al Server Timing aiutano ad analizzare con maggiore precisione le sezioni coinvolte.

CrUX, RUM proprio e laboratorio

Per iniziare, non è necessario utilizzare subito un proprio sistema di monitoraggio. PageSpeed Insights integra i dati raccolti sul campo provenienti dal Rapporto sull'esperienza utente di Chrome (CrUX) con una diagnosi di laboratorio Lighthouse. Le due prospettive rispondono a domande diverse: una descrive le esperienze registrate, l’altra analizza una pagina in condizioni controllate.

I dati sul campo CrUX in PageSpeed Insights descrivono un periodo retrospettivo di 28 giorni. Se i dati relativi a un URL specifico non sono sufficienti, il rapporto può mostrare invece i dati dell’origine. Questi includono l’origine del sito web corrispondente e non sono da equiparare all’esperienza effettiva sulla pagina specificata. Presta quindi attenzione al livello effettivo a cui si riferisce il rapporto.

CrUX tiene conto solo degli utenti di Chrome che soddisfano i rispettivi requisiti; gli altri browser e gli utenti non autorizzati non vengono considerati. Su un sito web di piccole dimensioni o non pubblico, i dati CrUX potrebbero non essere disponibili. Una raccolta autonoma, adeguata dal punto di vista giuridico e tecnico, può comunque fornire alcune informazioni, ma rimane statisticamente limitata in caso di poche visite.

Il monitoraggio sintetico ripete test predefiniti, anche quando nessuno sta visitando il sito web. È adatto per osservare regolarmente un flusso di navigazione in condizioni simili. Per stabilire se gli utenti che utilizzano dispositivi o reti diversi abbiano la stessa esperienza, è necessario effettuare una misurazione sul campo; un singolo flusso sintetico non può sostituire questa prospettiva.

Per la scelta è quindi determinante la domanda a cui desideri rispondere: un rapporto pubblico è rapidamente disponibile, mentre un sistema proprio consente una raccolta più mirata dei dati. Un servizio può alleggerire il carico di lavoro operativo, mentre il laboratorio e i test sintetici consentono analisi controllate. Tuttavia, anche un servizio richiede una selezione consapevole dei dati e dei gruppi di analisi.

Prepararsi in modo sicuro per effettuare una misurazione autonoma

Per prima cosa, definisci una domanda concreta, ad esempio se le pagine dei prodotti per dispositivi mobili presentano più spesso un LCP elevato rispetto ad altri tipi di pagine. Stabilisci poi quali pagine e classi di dispositivi intendi distinguere, quali metriche sono necessarie a tal fine e per quanto tempo desideri raccogliere i dati. Solo dopo potrai decidere lo script di misurazione, il destinatario e l’analisi dei dati.

Come primo passo tecnico, puoi utilizzare la libreria web-vitals integrarlo localmente in un progetto browser e visualizzarne l'output negli strumenti di sviluppo. Il codice JavaScript riportato di seguito utilizza la versione 6.2.3 del pacchetto pubblicato. Si presuppone che tale versione sia installata nel progetto e che la build gestisca le importazioni dei moduli. L'esempio non invia dati a un server e non attiva alcuna misurazione separata delle navigazioni soft.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

L'output della console è un modo per verificare l'integrazione, non una prova della velocità dei tuoi visitatori. Apri la pagina del progetto e interagisci, ad esempio, con un filtro. Un valore INP presuppone un’interazione adeguata e non deve necessariamente apparire immediatamente; in assenza di un’interazione adeguata, potrebbe non comparire affatto. Anche il supporto del browser e il ciclo di vita della pagina influenzano il risultato.

Prepara, in vista di un'analisi successiva, il Ciclo di vita della pagina Nota: i feedback possono verificarsi più volte, ad esempio quando una pagina viene nascosta e successivamente visualizzata nuovamente. Non considerare questi messaggi come visite indipendenti in modo generalizzato. La libreria fornisce degli ID di metrica che consentono di associare i messaggi alla stessa metrica.

Anche un ripristino dalla cache Back/Forward richiede una gestione specifica. Può generare un nuovo messaggio di metrica, sebbene il documento provenga dalla cache. Definisci come distinguere tali recuperi dalle normali navigazioni nel tuo report e consulta le indicazioni specifiche della libreria prima di configurare una raccolta in ambiente di produzione.

Analizzare i valori misurati per segmento

Un valore complessivo relativo al negozio online può nascondere il fatto che proprio le pagine dei prodotti su dispositivi mobili siano più lente. Suddividi quindi i dati di misurazione almeno per tipo di pagina e classe di dispositivo e considera per ogni metrica un periodo di tempo ben definito. In questo modo, ad esempio, potrai confrontare le pagine dei prodotti su dispositivi mobili con le pagine delle categorie su dispositivi mobili, invece di mescolare inavvertitamente situazioni di utilizzo diverse.

Per ogni segmento, il 75° percentile più significativo di una semplice media: indica il valore che almeno il 75% circa delle esperienze prese in considerazione non supera. Una media bassa può invece nascondere il fatto che un gruppo rilevante debba attendere a lungo. Confronta il p75 solo per la stessa metrica e con l’unità di misura appropriata.

Il numero di valori validi fa parte integrante del risultato. Se un segmento è costituito solo da poche misurazioni, i singoli dati possono influenzare notevolmente il percentile; in tal caso, una variazione non deve necessariamente indicare un problema generale. Se necessario, scegli un periodo di tempo più lungo oppure raggruppa pagine simili dal punto di vista tematico, senza compromettere la comparabilità dei dati.

Un INP mancante non è un INP veloce e non deve essere considerato pari a zero nella distribuzione. Indica invece separatamente il numero di valori INP validi. Se molte visite non forniscono un'interazione adeguata, l'analisi dell'INP descrive solo le esperienze di interazione registrate e non automaticamente tutte le visite alla pagina.

Raggruppa correttamente i messaggi ripetuti in base all’ID della metrica, invece di trattare ogni risposta come una nuova osservazione indipendente. Documenta inoltre come vengono conteggiati i ripristini dalla cache back/forward. In questo modo sarà possibile verificare quali osservazioni siano effettivamente incluse nel p75 e nel numero specificato.

Dal problema clinico alla diagnosi

Se i dati sul campo indicano una lentezza nelle pagine dei prodotti visualizzate su dispositivi mobili, limita innanzitutto il segmento interessato: il LCP scarso riguarda molti prodotti o solo un tipo di pagina? Verifica al contempo il periodo di riferimento e il numero di valori validi. In questo modo otterrai un punto di partenza per l’analisi, ma non ancora una prova di quale elemento causi il ritardo.

Inserisci quindi nel Test di laboratorio Ricrea condizioni il più possibile simili, ad esempio con una configurazione di dispositivo mobile e una velocità di rete limitata. Verifica quale elemento compare come LCP e quando viene caricato e visualizzato. Un’immagine di prodotto di grandi dimensioni, una richiesta di immagine tardiva o un percorso di rendering bloccato sono possibili ipotesi che devi verificare sulla base della diagnosi.

Se si riscontra un'indicazione relativa alla distribuzione di immagini, è possibile esaminarne le dimensioni, i formati e le modalità di messa a disposizione. Un Rete di distribuzione dei contenuti è una misura possibile, ma non garantisce un miglioramento dell'LCP. Se invece la risposta del documento indica la presenza di un collo di bottiglia, può essere utile un'ulteriore Benchmark del server per carichi di lavoro PHP, esaminare l'applicazione in condizioni ben definite.

Nel caso di un filtro di prodotto ritardato, è l’interazione a essere determinante, non il processo di caricamento. Simula il clic sul filtro e verifica quali operazioni vengono eseguite prima che l’aggiornamento sia visibile. Laddove il browser lo supporti, è possibile Fotogrammi di animazione lunghi Forniscono indicazioni sui tempi di rendering prolungati e sugli script coinvolti; tuttavia, non spiegano automaticamente ogni interazione lenta.

Applica una modifica mirata e poi osserva nuovamente lo stesso gruppo di pagine sul campo. Un risultato di laboratorio migliore mostra inizialmente solo l'effetto nelle condizioni di test selezionate. Solo la successiva valutazione sul campo potrà dimostrare se anche le esperienze registrate dei visitatori reali siano cambiate.

Qualità dei dati e protezione dei dati nell'ambito aziendale

Prima di passare alla fase operativa, stabilisci quali valori di misurazione sono necessari per la tua analisi e chi se ne occuperà. La pianificazione deve includere una trasmissione sicura al destinatario, restrizioni di accesso, un periodo di conservazione limitato e una procedura di cancellazione. Verifica gli aspetti relativi alla protezione dei dati e al consenso per l’implementazione concreta e le norme vigenti in modo specifico, anziché dare per scontata un’autorizzazione generica.

Con il Minimizzazione dei dati Vale la pena dare un’occhiata ai campi di diagnosi: gli URL completi possono contenere informazioni sensibili nei parametri di query; anche i selettori DOM possono rivelare dettagli sui contenuti delle pagine o sugli input. Se possibile, registra un tipo di pagina generico e pochi attributi selezionati in modo mirato. Verifica inoltre quali dati aggiuntivi vengono raccolti o memorizzati da un servizio integrato.

I valori misurati non sono sempre disponibili immediatamente. La libreria web-vitals può generare feedback più volte nel corso del ciclo di vita della pagina; un messaggio successivo non deve quindi essere considerato automaticamente come una nuova visita indipendente. Definire come vengono elaborati i messaggi correlati e come vengono gestiti i ripristini dalla cache «Indietro/Avanti».

Per i pacchetti diagnostici di piccole dimensioni, è possibile effettuare la trasmissione tramite sendBeacon durante l'evento visibilitychange essere idoneo. Ciò migliora la possibilità di inviare dati quando si nasconde una pagina, ma non garantisce la consegna. Il destinatario deve inoltre accettare i dati in modo sicuro ed elaborarli in modo tale che i messaggi ripetuti non falsino l'analisi senza che ciò venga notato.

Infine, tieni conto della Lacune nella raccolta dei dati: Gli script bloccati, il mancato supporto da parte del browser o le trasmissioni perse possono comportare la mancata registrazione di alcune visite. Valuta una percentuale stimata di perdita insieme al tipo di rilevamento. I dati di misurazione rimanenti descrivono il gruppo osservato e potrebbero non rappresentare in modo equo tutti i visitatori.

Valutare le modifiche e scegliere la procedura

Per effettuare un confronto dopo un’implementazione, definisci in anticipo quali tipi di pagina, classi di dispositivi e periodi di tempo prendere in considerazione. Confronta, per ogni metrica, il 75° percentile e il numero di valori validi prima e dopo la modifica. Intervalli di tempo di durata simile aiutano a contestualizzare i dati; tuttavia, ciò non garantisce automaticamente la disponibilità di campioni sufficientemente comparabili.

Presta attenzione a eventuali variazioni nella composizione del traffico. Se, dopo un’implementazione, aumenta il numero di utenti con connessioni mobili lente, il valore complessivo potrebbe peggiorare, anche se la modifica in sé non comporta un rallentamento. Anche l’utilizzo stagionale o altri cambiamenti concomitanti rendono difficile l’attribuzione. Una correlazione temporale è quindi un’ipotesi, non un Dimostrazione della causalità.

CrUX e il proprio RUM non devono necessariamente fornire gli stessi risultati: possono coprire gruppi di utenti, fasce orarie e condizioni di rilevamento diversi. Nel caso del CLS, va inoltre considerato che CrUX tiene conto anche del contributo dei frame incorporati all’esperienza della pagina principale. Una misurazione JavaScript nel documento principale non sempre rileva questi contributi in modo completo. Pertanto, è opportuno confrontare innanzitutto le basi di misurazione prima di interpretare una discrepanza come un errore.

Nel caso di un'applicazione a pagina singola, dovresti stabilire se intendi analizzare la navigazione tra i documenti o i cambi di percorso interni. Per la registrazione separata di Navigazione morbida A partire dalla versione 6, Web Vitals supporta l'opzione, a condizione che il browser la supporti reportSoftNavs: true. Deve essere impostata nei rispettivi callback delle metriche. L'esempio precedente in console, senza questa opzione, non attiva una misurazione separata del percorso.

Quando è attivata la registrazione della navigazione soft, i valori CLS e INP vengono azzerati per la nuova navigazione e considerati separatamente; i valori della navigazione precedente vengono chiusi al momento del cambio di percorso. Non dovresti confrontare tali valori, definiti in intervalli di tempo diversi, con le misurazioni a livello di documento senza prima averli verificati. Senza un supporto adeguato da parte del browser, l’opzione non comporta una misurazione separata del percorso.

Per scegliere un servizio RUM, oltre alla copertura dei browser, verifica se è possibile analizzare i gruppi di pagine e le classi di dispositivi necessari. Informati sulle procedure di campionamento, sull’elaborazione dei dati, sulla conservazione e sulle possibilità di esportazione. Altrettanto importante è valutare quale impatto possa avere lo script di misurazione stesso sulla pagina e se la sua raccolta dati possa essere limitata a quanto necessario per la tua analisi.