RAIL è un modello di prestazioni incentrato sull'utente che fornisce una struttura per riflettere sulle prestazioni. Il modello suddivide l'esperienza dell'utente in azioni chiave (ad esempio tocco, scorrimento, caricamento) e ti aiuta a definire gli obiettivi di rendimento per ciascuna di queste azioni.
RAIL è l'acronimo di quattro aspetti distinti del ciclo di vita delle app web: risposta, animazione, inattività e caricamento. Gli utenti hanno aspettative di rendimento diverse per ciascuno di questi contesti, pertanto gli obiettivi di rendimento vengono definiti in base al contesto e alla ricerca UX su come gli utenti percepiscono i ritardi.
Attenzione all'utente
Fai degli utenti il punto focale delle tue iniziative per migliorare il rendimento. La tabella seguente descrive le metriche chiave relative al modo in cui gli utenti percepiscono i ritardi delle prestazioni:
Percezione dell'utente dei ritardi nelle prestazioni| Da 0 a 16 ms | Gli utenti sono eccezionalmente bravi a monitorare i movimenti e non amano le animazioni non fluide. Percepiscono le animazioni come fluide se vengono visualizzati 60 nuovi frame al secondo. Ciò significa 16 ms per frame, incluso il tempo necessario al browser per visualizzare il nuovo frame sullo schermo, lasciando all'app circa 10 ms per produrre un frame. |
| Da 0 a 100 ms | Rispondi alle azioni degli utenti entro questa finestra temporale e gli utenti avranno l'impressione che il risultato sia immediato. Se l'attesa è più lunga, la connessione tra azione e reazione si interrompe. |
| Da 100 a 1000 ms | All'interno di questa finestra, le cose sembrano far parte di una progressione naturale e continua di attività. Per la maggior parte degli utenti sul web, il caricamento delle pagine o la modifica delle visualizzazioni rappresenta un'attività. |
| 1000 ms o più | Oltre i 1000 millisecondi (1 secondo), gli utenti perdono la concentrazione sull'attività che stanno svolgendo. |
| 10.000 ms o più | Oltre i 10.000 millisecondi (10 secondi), gli utenti si sentono frustrati e probabilmente abbandonano le attività. Potrebbero tornare o meno in un secondo momento. |
Obiettivi e linee guida
Nel contesto di RAIL, i termini obiettivi e linee guida hanno significati specifici:
Obiettivi: metriche sul rendimento principali relative all'esperienza utente. Ad esempio, il tempo che intercorre tra il tocco e il rendering deve essere inferiore a 100 millisecondi. Poiché la percezione umana è relativamente costante, è improbabile che questi obiettivi cambino nel prossimo futuro.
Linee guida. Suggerimenti che ti aiutano a raggiungere gli obiettivi. Questi potrebbero essere specifici per le condizioni attuali dell'hardware e della connessione di rete e, pertanto, potrebbero cambiare nel tempo.
Risposta: elabora gli eventi in meno di 50 ms
Obiettivo: completa una transizione avviata dall'input dell'utente entro 100 ms, in modo che gli utenti abbiano l'impressione che le interazioni siano istantanee.
Linee guida:
Per garantire una risposta visibile entro 100 ms, elabora gli eventi di input dell'utente entro 50 ms. Questo vale per la maggior parte degli input, come il clic sui pulsanti, l'attivazione/disattivazione dei controlli dei moduli o l'avvio di animazioni. Questo non si applica ai trascinamenti o agli scorrimenti con il tocco.
Anche se può sembrare controintuitivo, non è sempre la scelta giusta rispondere immediatamente all'input dell'utente. Puoi utilizzare questa finestra di 100 ms per eseguire altre operazioni costose, ma fai attenzione a non bloccare l'utente. Se possibile, esegui il lavoro in background.
Per le azioni che richiedono più di 50 ms per essere completate, fornisci sempre un feedback.
50 ms o 100 ms?
L'obiettivo è rispondere all'input in meno di 100 ms, quindi perché il nostro budget è di soli 50 ms? Questo perché, in genere, oltre alla gestione degli input, vengono eseguiti altri lavori che occupano parte del tempo disponibile per una risposta accettabile agli input. Se un'applicazione esegue il lavoro in blocchi di 50 ms consigliati durante il tempo di inattività, significa che l'input può essere messo in coda per un massimo di 50 ms se si verifica durante uno di questi blocchi di lavoro. Tenendo conto di questo, è sicuro presumere che solo i restanti 50 ms siano disponibili per la gestione effettiva degli input. Questo effetto è visualizzato nel diagramma seguente, che mostra come l'input ricevuto durante un'attività inattiva viene messo in coda, riducendo il tempo di elaborazione disponibile:
Animazione: genera un frame in 10 ms
Obiettivi:
Genera ogni frame di un'animazione in massimo 10 ms. Tecnicamente, il budget massimo per ogni frame è di 16 ms (1000 ms/60 frame al secondo ≈ 16 ms), ma i browser hanno bisogno di circa 6 ms per eseguire il rendering di ogni frame, da qui la linea guida di 10 ms per frame.
Punta alla fluidità visiva. Gli utenti notano quando le frequenze fotogrammi variano.
Linee guida:
Nei punti di alta pressione come le animazioni, la chiave è non fare nulla dove puoi e il minimo assoluto dove non puoi. Se possibile, sfrutta la risposta di 100 ms per precalcolare il lavoro oneroso in modo da massimizzare le possibilità di raggiungere i 60 fps.
Consulta Prestazioni di rendering per varie strategie di ottimizzazione delle animazioni.
- Animazioni visive, come entrate e uscite, tween e indicatori di caricamento.
- Scorrimento. Questo include lo scorrimento rapido, ovvero quando l'utente inizia a scorrere, poi rilascia e la pagina continua a scorrere.
- Trascinamento. Le animazioni spesso seguono le interazioni dell'utente, come la panoramica di una mappa o il gesto di pizzicare per aumentare lo zoom.
Inattivo: massimizza il tempo di inattività
Obiettivo: massimizzare il tempo di inattività per aumentare le probabilità che la pagina risponda all'input utente entro 50 ms.
Linee guida:
Utilizza il tempo di inattività per completare il lavoro differito. Ad esempio, per il caricamento iniziale della pagina, carica il minor numero possibile di dati, quindi utilizza il tempo di inattività per caricare il resto.
Esegui il lavoro durante il tempo di inattività in 50 ms o meno. Se l'operazione richiede più tempo, rischi di interferire con la capacità dell'app di rispondere all'input dell'utente entro 50 ms.
Se un utente interagisce con una pagina durante il lavoro in tempo di inattività, l'interazione dell'utente deve sempre avere la priorità più alta e interrompere il lavoro in tempo di inattività.
Caricamento: pubblicazione dei contenuti e interattività in meno di 5 secondi
Quando il caricamento pagina è lento, l'attenzione degli utenti si disperde e questi ultimi percepiscono l'attività come interrotta. I siti che si caricano rapidamente hanno sessioni medie più lunghe, frequenze di rimbalzo più basse e una maggiore visibilità degli annunci.
Obiettivi:
Ottimizza le prestazioni di caricamento rapido in base alle funzionalità dei dispositivi e della rete dei tuoi utenti. Al momento, un buon obiettivo per i primi caricamenti è caricare la pagina ed essere interattivi in 5 secondi o meno su dispositivi mobili di fascia media con connessioni 3G lente.
Per i caricamenti successivi, un buon obiettivo è caricare la pagina in meno di 2 secondi.
Linee guida:
Testa le prestazioni di caricamento sui dispositivi mobili e sulle connessioni di rete comunemente utilizzati dai tuoi utenti. Puoi utilizzare il Chrome User Experience Report per scoprire la distribuzione della connessione dei tuoi utenti. Se i dati non sono disponibili per il tuo sito, The Mobile Economy 2019 suggerisce che una buona base di riferimento globale è un telefono Android di fascia media, come un Moto G4, e una rete 3G lenta (definita come RTT di 400 ms e velocità di trasferimento di 400 kbps). Questa combinazione è disponibile su WebPageTest.
Tieni presente che, anche se il dispositivo del tuo utente mobile tipico potrebbe indicare che è connesso a una rete 2G, 3G o 4G, in realtà la velocità di connessione effettiva è spesso notevolmente inferiore, a causa della perdita di pacchetti e della variazione della rete.
Non è necessario caricare tutto in meno di 5 secondi per dare l'impressione di un caricamento completo. Valuta la possibilità di caricare lentamente le immagini, suddividere i bundle JavaScript e applicare altre ottimizzazioni suggerite su web.dev.
Strumenti per la misurazione di RAIL
Esistono alcuni strumenti che ti aiutano ad automatizzare le misurazioni RAIL. La scelta dipende dal tipo di informazioni di cui hai bisogno e dal tipo di flusso di lavoro che preferisci.
Chrome DevTools
Chrome DevTools fornisce un'analisi approfondita di tutto ciò che accade durante il caricamento pagina o l'esecuzione. Consulta Inizia ad analizzare le prestazioni di runtime per acquisire familiarità con l'interfaccia utente del riquadro Prestazioni.
Le seguenti funzionalità di DevTools sono particolarmente pertinenti:
Limita la CPU per simulare un dispositivo meno potente.
Limita la larghezza di banda della rete per simulare connessioni più lente.
Visualizza l'attività del thread principale per visualizzare ogni evento che si è verificato nel thread principale durante la registrazione.
Visualizza le attività del thread principale in una tabella per ordinarle in base a quelle che hanno richiesto più tempo.
Analizza i frame al secondo (FPS) per misurare se le tue animazioni vengono eseguite in modo fluido.
Monitora l'utilizzo della CPU, le dimensioni dell'heap JS, i nodi DOM, i layout al secondo e altro ancora in tempo reale con Monitoraggio del rendimento.
Visualizza le richieste di rete che si sono verificate durante la registrazione con la sezione Rete.
Acquisisci screenshot durante la registrazione per riprodurre esattamente l'aspetto della pagina durante il caricamento pagina, l'attivazione di un'animazione e così via.
Visualizza le interazioni per identificare rapidamente cosa è successo su una pagina dopo che un utente ha interagito con questa.
Trova i problemi di prestazioni di scorrimento in tempo reale evidenziando la pagina ogni volta che viene attivato un listener potenzialmente problematico.
Visualizza gli eventi di disegno in tempo reale per identificare gli eventi di disegno costosi che potrebbero compromettere le prestazioni delle tue animazioni.
Faro
Lighthouse è disponibile in Chrome DevTools, in PageSpeed Insights, come estensione di Chrome, come modulo Node.js e all'interno di WebPageTest. Fornisci un URL, simula un dispositivo di fascia media con una connessione 3G lenta, esegue una serie di controlli sulla pagina e poi ti fornisce un report sulle prestazioni di caricamento, oltre a suggerimenti su come migliorare.
I seguenti controlli sono particolarmente pertinenti:
Risposta
First Input Delay potenziale massimo. Stima il tempo necessario alla tua app per rispondere all'input utente, in base al tempo di inattività del thread principale.
Non utilizza listener passivi per migliorare le prestazioni di scorrimento.
Total Blocking Time. Misura il tempo totale durante il quale una pagina non può rispondere all'input dell'utente, ad esempio clic del mouse, tocchi dello schermo o pressioni della tastiera.
Time to Interactive. Misura quando un utente può interagire in modo coerente con tutti gli elementi della pagina.
Caricamento
Non registra un service worker che controlla la pagina e start_url. Un service worker può memorizzare nella cache le risorse comuni sul dispositivo di un utente, riducendo il tempo impiegato per recuperare le risorse dalla rete.
Il caricamento della pagina non è abbastanza veloce sulle reti mobili.
Rimanda le immagini fuori schermo. Rimanda il caricamento delle immagini fuori schermo finché non sono necessarie.
Usa immagini di dimensioni adeguate. Non pubblicare immagini di dimensioni significativamente maggiori rispetto a quelle visualizzate nell'area visibile mobile.
Evita dimensioni eccessive del DOM. Riduci i byte di rete inviando solo i nodi DOM necessari per il rendering della pagina.
WebPageTest
WebPageTest è uno strumento per le prestazioni web che utilizza browser reali per accedere alle pagine web e raccogliere metriche di temporizzazione. Inserisci un URL all'indirizzo webpagetest.org/easy per ottenere un report dettagliato sulle prestazioni di caricamento della pagina su un dispositivo Moto G4 reale con una connessione 3G lenta. Puoi anche configurarlo in modo da includere un controllo Lighthouse.
Riepilogo
RAIL è una lente attraverso cui osservare l'esperienza utente di un sito web come un percorso composto da interazioni distinte. Comprendi in che modo gli utenti percepiscono il tuo sito per impostare obiettivi di rendimento con il maggiore impatto sull'esperienza utente.
Progettata per l'utente
Rispondi all'input dell'utente in meno di 100 ms.
Generare un frame in meno di 10 ms durante l'animazione o lo scorrimento.
Massimizza il tempo di inattività del thread principale.
Carica i contenuti interattivi in meno di 5000 ms.