Metriche sul rendimento incentrate sull'utente

Tutti abbiamo sentito quanto sia importante il rendimento. Ma quando parliamo di rendimento e di "velocità" dei siti web, che cosa intendiamo nello specifico?

La verità è che il rendimento è relativo:

  • Un sito potrebbe essere veloce per un utente (su una rete veloce con un dispositivo potente) ma lento per un altro utente (su una rete lenta con un dispositivo di fascia bassa).
  • Due siti potrebbero terminare il caricamento con lo stesso lasso di tempo, ma uno può sembrare caricarsi più velocemente se i contenuti vengono caricati progressivamente, invece di aspettare la fine per visualizzare qualsiasi cosa.
  • Un sito potrebbe sembrare caricarsi rapidamente, ma poi rispondere lentamente o non rispondere affatto all'interazione dell'utente.

Quando si parla di prestazioni, è importante essere precisi e fare riferimento al rendimento in termini di metrics, criteri oggettivi che possono essere misurati quantitativamente. Ma è anche importante assicurarsi che le metriche che misuri siano utili.

Metriche

Storicamente, le prestazioni web sono state misurate con l'evento load. Tuttavia, anche se load è un momento ben definito del ciclo di vita di una pagina, questo momento non corrisponde necessariamente a ciò che interessa all'utente.

Ad esempio, un server potrebbe rispondere con una pagina minima che si "carica" immediatamente, ma poi rinvia il recupero dei contenuti o la visualizzazione di qualsiasi elemento sulla pagina fino a diversi secondi dopo l'attivazione dell'evento load. Una pagina del genere ha tecnicamente un tempo di caricamento veloce, ma questo lasso di tempo non corrisponde a come l'utente la carica.

Negli ultimi anni, i membri del team di Chrome, in collaborazione con il W3C Web Performance Working Group, hanno lavorato per standardizzare un insieme di nuove API e metriche che misurano in modo più accurato l'esperienza degli utenti rispetto alle prestazioni di una pagina web.

Per fare in modo che le metriche siano pertinenti per gli utenti, le sottoponiamo ad alcune domande chiave:

Sta succedendo? La navigazione è stata avviata correttamente? Il server ha risposto?
È utile? Il rendering dei contenuti è sufficiente per consentire agli utenti di interagire?
È utilizzabile? Gli utenti possono interagire con la pagina o la pagina è occupata?
È delizioso? Le interazioni sono fluide e naturali, prive di ritardi e jank?

Come vengono misurate le metriche

Generalmente le metriche sul rendimento vengono misurate in due modi:

  • In lab: utilizzo di strumenti per simulare un caricamento di pagina in un ambiente coerente e controllato
  • In campo: quando utenti reali caricano e interagiscono con la pagina.

Nessuna di queste opzioni è necessariamente migliore o peggiore dell'altra. Infatti, generalmente è consigliabile utilizzare entrambi per garantire un buon rendimento.

Nel laboratorio

Testare le prestazioni in laboratorio è essenziale quando si sviluppano nuove funzionalità. Prima che le funzionalità vengano rilasciate in produzione, è impossibile misurare le loro caratteristiche di prestazioni su utenti reali, quindi testarle nel lab prima del rilascio della funzionalità è il modo migliore per evitare regressioni delle prestazioni.

Sul campo

D'altra parte, sebbene i test in lab siano un ragionevole sostituto delle prestazioni, non rispecchia necessariamente l'esperienza di tutti gli utenti sul tuo sito.

Le prestazioni di un sito possono variare drasticamente in base alle funzionalità del dispositivo dell'utente e alle condizioni della rete. Può variare anche a seconda che l'utente interagisci con la pagina (o come).

Inoltre, i caricamenti delle pagine non sono sempre deterministici. Ad esempio, i siti che caricano contenuti o annunci personalizzati possono avere caratteristiche di rendimento molto diverse da utente a utente. Un test di laboratorio non coglierà queste differenze.

L'unico modo per conoscere appieno le prestazioni di un sito per gli utenti è misurarne le prestazioni mentre gli utenti lo caricano e vi interagiscono. Questo tipo di misurazione è comunemente chiamato Real User Monitoring (RUM).

Tipi di metriche

Esistono molti altri tipi di metriche pertinenti per il modo in cui gli utenti percepiscono il rendimento:

  • Velocità di caricamento percepita: la velocità con cui una pagina può caricarsi e visualizzare tutti i suoi elementi visivi sullo schermo.
  • Adattabilità del caricamento: la velocità con cui una pagina può caricare ed eseguire qualsiasi codice JavaScript necessario affinché i componenti rispondano rapidamente all'interazione dell'utente.
  • Reattività durante l'esecuzione: la velocità con cui una pagina può rispondere all'interazione dell'utente dopo il caricamento.
  • Stabilità visiva: gli elementi del cambio di pagina sono diversi da quelli che gli utenti aspettano e che potrebbero interferire con le loro interazioni?
  • Uniformità: le transizioni e le animazioni vengono visualizzate con una frequenza fotogrammi costante e scorrono in modo fluido da uno stato all'altro?

Alla luce di tutti questi tipi di metriche sul rendimento, è chiaro che nessuna singola metrica è sufficiente per acquisire tutte le caratteristiche delle prestazioni di una pagina.

Metriche importanti da misurare

First Contentful Paint (FCP)
Il tempo che intercorre tra l'inizio del caricamento della pagina e il momento in cui qualsiasi parte dei contenuti della pagina viene visualizzata sullo schermo. (lab, campo)
LCP (Largest Contentful Paint)
Il tempo che intercorre tra l'inizio del caricamento della pagina e il momento in cui viene visualizzato sullo schermo il blocco di testo o l'elemento immagine più grande. (lab, campo)
Interazione con Next Paint (INP)
La latenza di ogni tocco, clic o interazione da tastiera effettuata con la pagina. In base al numero di interazioni, questa metrica seleziona la latenza di interazione peggiore (o più vicina alla peggiore) della pagina come singolo valore rappresentativo per descrivere l'adattabilità complessiva di una pagina. (lab, campo)
Tempo di blocco totale (TBT)
Il tempo totale tra FCP e Tempo all'interattività (TTI) in cui il thread principale è stato bloccato per il tempo necessario a impedire la reattività all'input. (lab)
Cumulative Layout Shift (CLS)
Il punteggio cumulativo di tutte le variazioni di layout impreviste che si verificano tra l'inizio del caricamento della pagina e il momento in cui lo stato di ciclo di vita passa a nascosto. (lab, campo)
Tempo per il primo byte (TTFB)
Il tempo impiegato dalla rete per rispondere alla richiesta di un utente con il primo byte di una risorsa. (lab, campo)

Questo elenco include metriche che misurano molti dei vari aspetti del rendimento pertinenti per gli utenti, ma non include tutti i dati. Ad esempio, non sono coperti i tempi di risposta e fluidità del runtime.

In alcuni casi, verranno introdotte nuove metriche per coprire le aree mancanti, ma in altri le metriche migliori sono quelle personalizzate specificamente per il tuo sito.

Metriche personalizzate

Le metriche sul rendimento elencate di seguito sono utili per ottenere una comprensione generale delle caratteristiche del rendimento della maggior parte dei siti sul web. Sono utili anche per avere un insieme comune di metriche per i siti per confrontare il loro rendimento con quello della concorrenza.

Tuttavia, può capitare che un sito specifico sia unico in qualche modo che richieda metriche aggiuntive per avere un quadro completo del rendimento. Ad esempio, la metrica LCP ha lo scopo di misurare quando è stato completato il caricamento dei contenuti principali di una pagina, ma potrebbero verificarsi casi in cui l'elemento più grande non fa parte dei contenuti principali della pagina, rendendo l'LCP irrilevante.

Per risolvere questi casi, il Web Performance Working Group ha anche standardizzato API di livello inferiore che possono essere utili per implementare metriche personalizzate:

Consulta la guida sulle metriche personalizzate per scoprire come utilizzare queste API per misurare le caratteristiche di prestazioni specifiche per il tuo sito.