RAIL è un modello di rendimento incentrato sull'utente che fornisce una struttura per pensare al rendimento. 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 sull'UX su come gli utenti percepiscono i ritardi.
Attenzione all'utente
Concentrati sugli utenti per migliorare il rendimento. La tabella seguente descrive le metriche chiave di come gli utenti percepiscono i ritardi nelle prestazioni:
Percezione degli utenti dei ritardi nelle prestazioni| Da 0 a 16 ms | Gli utenti sono particolarmente bravi a monitorare il movimento e non apprezzano le animazioni non fluide. Percepiscono le animazioni come fluide finché vengono renderizzati 60 nuovi frame al secondo. Si tratta di 16 ms per frame, incluso il tempo necessario al browser per disegnare 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 questo intervallo di tempo e gli utenti hanno la sensazione che il risultato sia immediato. Se il ritardo è maggiore, la connessione tra azione e reazione si interrompe. |
| Da 100 a 1000 ms | In questa finestra, le cose sembrano far parte di una progressione naturale e continua delle attività. Per la maggior parte degli utenti sul web, il caricamento delle pagine o il cambio di visualizzazione rappresenta un'attività. |
| 1000 ms o più | Oltre 1000 millisecondi (1 secondo), gli utenti perdono la concentrazione sull'attività che stanno svolgendo. |
| 10.000 ms o più | Oltre 10.000 millisecondi (10 secondi), gli utenti sono frustrati e probabilmente abbandonano le attività. Potrebbe tornare 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. Consigli 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: completare una transizione avviata dall'input dell'utente entro 100 ms, in modo che gli utenti percepiscano le interazioni come 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, ad esempio fare clic sui pulsanti, attivare/disattivare i controlli dei moduli o avviare animazioni. Questo non si applica ai trascinamenti o agli scorrimenti.
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 operazioni 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 vengono eseguite altre operazioni oltre alla gestione dell'input e queste operazioni occupano parte del tempo disponibile per una risposta accettabile all'input. Se un'applicazione esegue il lavoro nei blocchi di 50 ms consigliati durante il tempo di inattività, significa che l'input può essere messo in coda fino a 50 ms se si verifica durante uno di questi blocchi di lavoro. Tenendo conto di questo, è ragionevole supporre che siano disponibili solo i 50 ms rimanenti per la gestione effettiva dell'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: produrre un frame in 10 ms
Obiettivi:
Produci ogni frame di un'animazione in 10 ms o meno. 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 cui la linea guida di 10 ms per frame.
Punta a una fluidità visiva. Gli utenti notano quando i frame rate variano.
Linee guida:
Nei punti di alta pressione, come le animazioni, la cosa fondamentale è non fare nulla dove puoi e il minimo indispensabile dove non puoi. Se possibile, utilizza la risposta di 100 ms per precalcolare il lavoro costoso in modo da massimizzare le tue possibilità di raggiungere i 60 fps.
Consulta Rendering Performance per varie strategie di ottimizzazione delle animazioni.
- Animazioni visive, come entrate e uscite, tween e indicatori di caricamento.
- Scorrimento. Ciò 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, ad esempio la panoramica di una mappa o il pizzico per 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 posticipato. 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 il tempo è maggiore, 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 inattivo, l'interazione dell'utente deve sempre avere la massima priorità e interrompere il lavoro inattivo.
Caricamento: fornisci contenuti e diventa interattivo in meno di 5 secondi
Quando le pagine si caricano lentamente, l'attenzione degli utenti si sposta e gli utenti percepiscono l'attività come interrotta. I siti che si caricano rapidamente hanno sessioni medie più lunghe, tassi di rimbalzo inferiori e una visibilità degli annunci più elevata.
Obiettivi:
Ottimizza per prestazioni di caricamento rapide in base alle funzionalità del dispositivo e della rete dei tuoi utenti. Attualmente, un buon obiettivo per i primi caricamenti è caricare la pagina e renderla interattiva 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 comuni tra i tuoi utenti. Puoi utilizzare il Rapporto sull'esperienza utente di Chrome per scoprire la distribuzione delle connessioni dei tuoi utenti. Se i dati non sono disponibili per il tuo sito, il report The Mobile Economy 2019 suggerisce che una buona base di riferimento globale è un cellulare 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 tipo potrebbe indicare una connessione 2G, 3G o 4G, in realtà la velocità di connessione effettiva è spesso molto più lenta a causa della perdita di pacchetti e della varianza della rete.
Non devi caricare tutto in meno di 5 secondi per dare l'impressione di un caricamento completo. Valuta la possibilità di utilizzare il caricamento lento delle immagini, la divisione del codice dei bundle JavaScript e altre ottimizzazioni suggerite su web.dev.
Strumenti per misurare RAIL
Esistono alcuni strumenti per automatizzare le misurazioni RAIL. La scelta dipende dal tipo di informazioni che ti servono 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 la sezione Iniziare ad analizzare le prestazioni di runtime per familiarizzare 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 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 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 Performance Monitor.
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 o l'attivazione di un'animazione e così via.
Visualizza le interazioni per identificare rapidamente cosa è successo in una pagina dopo l'interazione di un utente.
Trova problemi di prestazioni di scorrimento in tempo reale evidenziando la pagina ogni volta che viene attivato un listener potenzialmente problematico.
Visualizza gli eventi di rendering in tempo reale per identificare gli eventi di rendering costosi che potrebbero danneggiare le prestazioni delle tue animazioni.
Faro
Lighthouse è disponibile in Chrome DevTools, in PageSpeed Insights, come estensione di Chrome, come modulo Node.js e in 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, nonché suggerimenti su come migliorare.
I seguenti controlli sono particolarmente pertinenti:
Risposta
First Input Delay potenziale max. Stima il tempo necessario alla tua app per rispondere all'input dell'utente, in base al tempo di inattività del thread principale.
Non usa listener passivi per migliorare le prestazioni di scorrimento.
Total Blocking Time. Misura il tempo totale in cui una pagina non risponde all'input dell'utente, ad esempio clic del mouse, tocchi dello schermo o pressioni dei tasti.
Tempo all'interattività. Misura il momento in cui 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 necessario per recuperare le risorse sulla rete.
Il caricamento della pagina non è abbastanza veloce sulle reti mobili.
Rimanda immagini fuori schermo. Posticipa il caricamento delle immagini fuori schermo finché non sono necessarie.
Usa immagini di dimensioni adeguate. Non pubblicare immagini significativamente più grandi delle dimensioni di rendering nell'area visibile mobile.
Evita di usare un DOM di dimensioni eccessive. Ridurre 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 sul rendimento di caricamento della pagina su un dispositivo Moto G4 reale con una connessione 3G lenta. Puoi anche configurarlo in modo che includa un controllo di Lighthouse.
Riepilogo
RAIL è un modo per esaminare l'esperienza utente di un sito web come un percorso composto da interazioni distinte. Comprendi come gli utenti percepiscono il tuo sito per impostare obiettivi di rendimento con il maggiore impatto sull'esperienza utente.
Progettata per l'utente
Rispondere all'input dell'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.