RAIL è un modello di prestazioni incentrata sull'utente che fornisce una struttura per valutare le prestazioni. Il modello suddivide l'esperienza utente in azioni chiave (ad esempio tocco, scorrimento, caricamento) e ti aiuta a definire gli obiettivi di rendimento per ciascuna di esse.
RAIL indica quattro aspetti distinti del ciclo di vita dell'app web: risposta, animazione, inattività e caricamento. Gli utenti hanno aspettative di prestazioni diverse per ciascuno di questi contesti, pertanto gli obiettivi di prestazioni sono definiti in base al contesto e alla ricerca sull'UX su come gli utenti percepiscono i ritardi.
Attenzione all'utente
Fai in modo che gli utenti siano il punto focale del tuo impegno per migliorare il rendimento. La tabella seguente descrive le metriche principali relative al modo in cui gli utenti percepiscono i ritardi nelle prestazioni:
Percezione degli utenti sui ritardi nel rendimento| Da 0 a 16 ms | Gli utenti sono molto bravi a monitorare il movimento e non apprezzano molto le animazioni non fluide. Percepiscono le animazioni in modo fluido purché vengano visualizzati 60 nuovi frame al secondo. Ciò corrisponde a 16 ms per frame, compreso il tempo necessario al browser per colorare il nuovo frame sullo schermo, lasciando all'app circa 10 ms per produrre un frame. |
| Da 0 a 100 ms | Se rispondi alle azioni degli utenti entro questo periodo di tempo, il risultato sarà immediato. Non sarà più necessario e la connessione tra azione e reazione si interrompe. |
| Da 100 a 1000 ms | All'interno di questa finestra, le cose sembrano parte di una progressione naturale e continua delle attività. Per la maggior parte degli utenti del Web, caricare pagine o modificare la visualizzazione rappresenta un'attività. |
| 1000 ms o più | Oltre 1000 millisecondi (1 secondo), gli utenti perdono la concentrazione sull'attività che stanno eseguendo. |
| 10.000 ms o più | Oltre 10.000 millisecondi (10 secondi), gli utenti sono frustrati ed è più probabile che abbandonino le attività. Potrebbe 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 chiave sul rendimento relative all'esperienza utente. Ad esempio, tocca per dipingere in meno di 100 millisecondi. Poiché la percezione umana è relativamente costante, è improbabile che questi obiettivi cambino a breve.
Linee guida. Suggerimenti utili per raggiungere gli obiettivi. Potrebbero essere specifici delle condizioni attuali dell'hardware e della connessione di rete e pertanto potrebbero cambiare nel tempo.
Risposta: elabora eventi in meno di 50 ms
Obiettivo: completare una transizione avviata in base all'input utente entro 100 ms, in modo che gli utenti abbiano la sensazione che le interazioni siano istantanee.
Linee guida:
Per garantire una risposta visibile entro 100 ms, elabora gli eventi di input utente entro 50 ms. Questo vale per la maggior parte degli input, ad esempio clic su pulsanti, attivazione/disattivazione dei controlli del modulo o avvio di animazioni. Questo non vale per i trascinamento o lo scorrimento al tocco.
Anche se può sembrare controintuitivo, non è sempre la scelta giusta per rispondere immediatamente all'input dell'utente. Puoi utilizzare questa finestra di 100 ms per svolgere altre operazioni costose, ma fai attenzione a non bloccare l'utente. Se possibile, lavora in background.
Per azioni il cui completamento richiede più di 50 ms, fornisci sempre 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é generalmente vengono svolte altre attività oltre alla gestione dell'input, che richiede parte del tempo disponibile per una risposta di input accettabile. Se un'applicazione esegue operazioni nei blocchi consigliati di 50 ms 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 ciò, si può presumere che siano disponibili solo i 50 ms rimanenti per la gestione effettiva dell'input. Questo effetto è visualizzato nel diagramma seguente, che mostra come viene messo in coda l'input ricevuto durante un'attività inattiva, riducendo il tempo di elaborazione disponibile:
Animazione: produci un fotogramma in 10 ms
Obiettivi:
Produci ogni frame in un'animazione in una durata massima di 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, quindi la linea guida di 10 ms per frame.
Cerca di ottenere una fluidità visiva. Gli utenti notano quando le frequenze fotogrammi variano.
Linee guida:
Nei punti di maggiore pressione come le animazioni, è fondamentale non fare nulla dove puoi e il minimo assoluto dove non puoi. Se possibile, sfrutta la risposta di 100 ms per precalcolare attività costose in modo da massimizzare le possibilità di raggiungere i 60 fps.
Consulta la sezione Prestazioni del rendering per conoscere le varie strategie di ottimizzazione delle animazioni.
- Animazioni visive, ad esempio entrate e uscite, intervalli e indicatori di caricamento.
- Scorrimento. È incluso lo scorrimento, ovvero quando l'utente inizia a scorrere per poi rilasciarlo e la pagina continua a scorrere.
- Trascinamento. Le animazioni spesso seguono le interazioni degli utenti, ad esempio la panoramica di una mappa o le azioni di pizzicatura per eseguire lo zoom.
Inattivo: massimizza il tempo di inattività
Obiettivo: massimizzare il tempo di inattività per aumentare le probabilità che la pagina risponda all'input dell'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 la minor quantità di dati possibile, poi utilizza il tempo di inattività per caricare il resto.
Esegui le operazioni durante il tempo di inattività di massimo 50 ms. Ancora più tempo e rischi di interferire con la capacità dell'app di rispondere all'input utente entro 50 ms.
Se un utente interagisce con una pagina durante il funzionamento in caso di inattività, l'interazione dell'utente deve sempre avere la massima priorità e interrompere il funzionamento in caso di inattività.
Caricamento: pubblica contenuti e diventa interattivo in meno di 5 secondi
Quando le pagine si caricano lentamente, l'attenzione degli utenti vaga e gli utenti percepiscono l'attività come interrotta. I siti che vengono caricati rapidamente presentano sessioni medie più lunghe, frequenze di rimbalzo inferiori e una maggiore visibilità degli annunci.
Obiettivi:
Ottimizza le prestazioni del caricamento rapido in relazione alle funzionalità del dispositivo e della rete dei tuoi utenti. Attualmente, un buon target per i primi caricamenti è quello di caricare la pagina ed essere interattivi in 5 secondi o meno sui dispositivi mobili di fascia media con connessioni 3G lente.
Per i caricamenti successivi, è consigliabile caricare la pagina in meno di due secondi.
Linee guida:
Testa le prestazioni di carico sui dispositivi mobili e sulle connessioni di rete comuni tra i tuoi utenti. Puoi utilizzare il Report sull'esperienza utente di Chrome per trovare la distribuzione delle connessioni 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 sia 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 dell'utente mobile tipico potrebbe affermare di utilizzare una connessione 2G, 3G o 4G, in realtà la velocità di connessione effettiva è spesso notevolmente più lenta, a causa della perdita di pacchetti e della varianza della rete.
Non è necessario caricare tutto in meno di 5 secondi per generare l'impressione di un caricamento completo. Prendi in considerazione immagini con caricamento lento, bundle JavaScript con suddivisione del codice e altre ottimizzazioni suggerite su web.dev.
Strumenti per misurare RAIL
Esistono alcuni strumenti per aiutarti ad automatizzare le misurazioni RAIL. La soluzione da utilizzare dipende dal tipo di informazioni necessarie 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 o l'esecuzione della pagina. Consulta Introduzione all'analisi delle prestazioni del runtime per acquisire familiarità con l'interfaccia utente del riquadro Prestazioni.
Le seguenti funzionalità DevTools sono particolarmente pertinenti:
Limita la CPU per simulare un dispositivo meno potente.
Limita la rete per simulare connessioni più lente.
Visualizza l'attività del thread principale per visualizzare tutti gli eventi che si sono verificati nel thread principale durante la registrazione.
Visualizza le attività dei thread principali in una tabella per ordinare le attività in base a quelle che hanno richiesto più tempo.
Analizza i frame al secondo (f/s) per misurare se le tue animazioni funzionano correttamente.
Monitora l'utilizzo della CPU, le dimensioni dello heap JS, i nodi DOM, i layout al secondo e altro ancora in tempo reale con Performance Monitor.
Visualizza le richieste di rete che si sono verificate durante la registrazione con la sezione Network.
Acquisisci screenshot durante la registrazione per riprodurre l'aspetto esatto della pagina durante il caricamento o l'attivazione di un'animazione e così via.
Visualizza le interazioni per identificare rapidamente ciò che è accaduto in una pagina dopo che un utente ha interagito con essa.
Individua i problemi di prestazioni dello scorrimento in tempo reale evidenziando la pagina ogni volta che si attiva un listener potenzialmente problematico.
Visualizza gli eventi di colorazione in tempo reale per identificare costosi eventi di colorazione che potrebbero danneggiare le prestazioni delle animazioni.
Faro
Lighthouse è disponibile in Chrome DevTools, su 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 connessione 3G lenta, esegue una serie di controlli sulla pagina, quindi ti fornisce un report sulle prestazioni di caricamento e suggerimenti su come migliorare.
I seguenti controlli sono particolarmente pertinenti:
Risposta
Max Potential First Input Delay. Stima il tempo impiegato dall'app per rispondere all'input utente, in base al tempo di inattività del thread principale.
Non utilizza listener passivi per migliorare le prestazioni dello scorrimento.
Tempo di blocco totale. Misura il tempo totale durante il quale una pagina non risponde agli input utente, come clic del mouse, tocchi sullo schermo o pressioni della tastiera.
Tempo all'interattività. 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 dedicato al recupero delle risorse sulla rete.
Il caricamento della pagina non è abbastanza veloce sulle reti mobili.
Rimanda le immagini fuori schermo. Rimanda il caricamento delle immagini fuori schermo fino a quando non sono necessarie.
Immagini di dimensioni corrette. Non pubblicare immagini significativamente più grandi rispetto alle dimensioni visualizzate nell'area visibile per dispositivi mobili.
Evita dimensioni del DOM eccessive. Riduci i byte di rete spedendo solo i nodi DOM necessari per il rendering della pagina.
WebPageTest
WebPageTest è uno strumento per ottimizzare le prestazioni web che utilizza browser reali per accedere a pagine web e raccogliere metriche di temporizzazione. Inserisci un URL all'indirizzo webpagetest.org/easy per ottenere un rapporto dettagliato sulle prestazioni di caricamento della pagina su un vero dispositivo Moto G4 con connessione 3G lenta. Puoi anche configurarlo in modo che includa un controllo Lighthouse.
Riepilogo
RAIL esamina l'esperienza utente di un sito web come un percorso composto da interazioni distinte. Scopri come gli utenti percepiscono il tuo sito al fine di definire obiettivi di rendimento con il maggiore impatto sull'esperienza utente.
Progettata per l'utente
Rispondi all'input utente in meno di 100 ms.
Produci un frame in meno di 10 ms durante l'animazione o lo scorrimento.
Massimizza il tempo di inattività del thread principale.
Carica contenuti interattivi in meno di 5000 ms.