Metriche sul rendimento incentrate sull'utente

Philip Walton

Tutti abbiamo sentito quanto sia importante il rendimento. Ma quando parliamo di prestazioni, e di come rendere i siti web "veloci", 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).
• Il caricamento di due siti potrebbe essere completato nello stesso lasso di tempo, ma uno potrebbe sembrare caricarsi più velocemente (se i contenuti vengono caricati progressivamente anziché aspettare la fine per visualizzare qualcosa).
• 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 a questo aspetto in termini di criteri oggettivi che possono essere misurati quantitativamente. Questi criteri sono noti come metrics.

Tuttavia, il semplice fatto che una metrica si basi su criteri oggettivi e possa essere misurata in modo quantitativo non significa necessariamente che queste misurazioni siano utili.

Definizione delle 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 "viene caricata" immediatamente, ma poi blocca il recupero dei contenuti e la visualizzazione di qualsiasi elemento sulla pagina fino a alcuni secondi dopo l'attivazione dell'evento load. Sebbene una pagina di questo tipo possa tecnicamente avere un tempo di caricamento rapido, questo lasso di tempo non corrisponde all'esperienza effettiva di caricamento della pagina da parte di un utente.

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:

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: in fatti, in genere è consigliabile utilizzarle entrambe per garantire un rendimento ottimale.

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 laboratorio siano un ragionevole sostituto per le prestazioni, non rispecchia necessariamente l'esperienza di tutti gli utenti sul tuo sito alla scoperta del tuo sito.

Le prestazioni di un sito possono variare notevolmente in base alle funzionalità del dispositivo dell'utente e alle condizioni della rete. Inoltre, può variare a seconda che l'utente interagisca con la pagina o in che modo.

Inoltre, il caricamento delle pagine potrebbe non essere deterministico. Ad esempio, i siti che caricano contenuti o annunci personalizzati potrebbero avere caratteristiche di rendimento molto diverse da utente a utente. Un test di laboratorio non può rilevare queste differenze.

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

Tipi di metriche

Esistono molti altri tipi di metriche pertinenti al 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 per consentire ai componenti di rispondere rapidamente all'interazione dell'utente.
• Reattività durante l'esecuzione: dopo il caricamento della pagina, la velocità con cui la pagina può rispondere all'interazione dell'utente.
• Stabilità visiva: gli elementi del cambio di pagina in modi che gli utenti non si aspettano e che potenzialmente interferiscono 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?

Tenendo conto di tutti i tipi di metriche sul rendimento illustrati sopra, è chiaro che nessuna singola metrica è sufficiente per acquisire tutte le caratteristiche prestazionali di una pagina.

Metriche importanti da misurare

• First Contentful Paint (FCP): misura 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): misura 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)
• First Input Delay (FID): misura il tempo trascorso tra la prima interazione di un utente con il tuo sito (quando fa clic su un link, tocca un pulsante o utilizza un controllo personalizzato basato su JavaScript) e il momento in cui il browser è effettivamente in grado di rispondere a quell'interazione. (campo)
• Interaction to Next Paint (INP): misura la latenza di ogni tocco, clic o interazione da tastiera effettuata con la pagina e, in base al numero di interazioni, seleziona la latenza di interazione peggiore della pagina (o vicina alla più alta) come un singolo valore rappresentativo per descrivere l'adattabilità complessiva di una pagina. (lab, campo)
• Tempo di blocco totale (TBT): misura la quantità totale di tempo tra FCP e TTI in cui il thread principale è stato bloccato per un tempo sufficiente a impedire la reattività dell'input. (lab)
• Cumulative Layout Shift (CLS): misura 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 il relativo stato del ciclo di vita passa a nascosto. (lab, campo)
• Tempo per il primo byte (TTFB): misura il tempo necessario alla rete per rispondere alla richiesta di un utente con il primo byte di una risorsa. (lab, campo)

Sebbene questo elenco includa metriche che misurano molti dei vari aspetti del rendimento pertinenti per gli utenti, non include tutto. Ad esempio, la reattività e l'uniformità del runtime non sono attualmente coperte.

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 sopra sono utili per avere una comprensione generale delle caratteristiche delle prestazioni della maggior parte dei siti sul web. Sono inoltre ottimi 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 e che richieda metriche aggiuntive per acquisire 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 e pertanto l'LCP potrebbe non essere pertinente.

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

• API User Timing
• API Long Tasks
• API Element Timing
• API Navigazione Timing
• API Resource Timing
• Tempistiche del server

Consulta la guida alle metriche personalizzate per scoprire come usare queste API per misurare le caratteristiche delle prestazioni specifiche per il tuo sito.