RAIL est un modèle de performances centré sur l'utilisateur qui fournit une structure pour réfléchir aux performances. Le modèle décompose l'expérience utilisateur en actions clés (par exemple, appuyer, faire défiler, charger) et vous aide à définir des objectifs de performances pour chacune d'elles.
RAIL est un acronyme qui désigne quatre aspects distincts du cycle de vie d'une application Web : réponse, animation, inactivité et chargement. Les utilisateurs ont des attentes différentes en termes de performances pour chacun de ces contextes. Les objectifs de performances sont donc définis en fonction du contexte et de la recherche sur l'expérience utilisateur concernant la façon dont les utilisateurs perçoivent les délais.
Centré sur l'utilisateur
Placez les utilisateurs au centre de vos efforts pour améliorer les performances. Le tableau ci-dessous décrit les principales métriques qui indiquent comment les utilisateurs perçoivent les ralentissements des performances :
Perception par les utilisateurs des délais de performances| 0 à 16 ms | Les utilisateurs sont particulièrement sensibles au mouvement et n'apprécient pas les animations non fluides. Ils perçoivent les animations comme fluides tant que 60 nouvelles images sont affichées chaque seconde. Cela représente 16 ms par frame, y compris le temps nécessaire au navigateur pour peindre le nouveau frame à l'écran, ce qui laisse à une application environ 10 ms pour produire un frame. |
| 0 à 100 ms | Répondez aux actions de l'utilisateur dans ce délai pour que l'utilisateur ait l'impression que le résultat est immédiat. Au-delà, le lien entre l'action et la réaction est rompu. |
| 100 à 1 000 ms | Dans cette fenêtre, les éléments semblent faire partie d'une progression naturelle et continue des tâches. Pour la plupart des utilisateurs sur le Web, le chargement de pages ou le changement de vue représentent une tâche. |
| 1 000 ms ou plus | Au-delà de 1 000 millisecondes (1 seconde), les utilisateurs perdent leur concentration sur la tâche qu'ils effectuent. |
| 10 000 ms ou plus | Au-delà de 10 000 millisecondes (10 secondes), les utilisateurs sont frustrés et sont susceptibles d'abandonner les tâches. Il est possible qu'il revienne plus tard. |
Objectifs et consignes
Dans le contexte de RAIL, les termes objectifs et consignes ont des significations spécifiques :
Objectifs : métriques de performances clés liées à l'expérience utilisateur. Par exemple, appuyez pour peindre en moins de 100 millisecondes. Étant donné que la perception humaine est relativement constante, il est peu probable que ces objectifs changent de sitôt.
Consignes Recommandations qui vous aident à atteindre vos objectifs. Elles peuvent être spécifiques aux conditions actuelles du matériel et de la connexion réseau, et peuvent donc changer au fil du temps.
Réponse : traiter les événements en moins de 50 ms
Objectif : Effectuer une transition initiée par une saisie utilisateur en moins de 100 ms, afin que les utilisateurs aient l'impression que les interactions sont instantanées.
Consignes :
Pour garantir une réponse visible dans les 100 ms, traitez les événements d'entrée utilisateur dans les 50 ms. Cela s'applique à la plupart des entrées, comme le fait de cliquer sur des boutons, d'activer ou de désactiver des commandes de formulaire ou de démarrer des animations. Cela ne s'applique pas aux déplacements ou aux défilements tactiles.
Bien que cela puisse sembler contre-intuitif, il n'est pas toujours judicieux de répondre immédiatement à l'entrée de l'utilisateur. Vous pouvez utiliser cette fenêtre de 100 ms pour effectuer d'autres tâches coûteuses, mais veillez à ne pas bloquer l'utilisateur. Si possible, effectuez le travail en arrière-plan.
Pour les actions qui prennent plus de 50 ms, fournissez toujours un retour.
50 ms ou 100 ms ?
L'objectif est de répondre à l'entrée en moins de 100 ms. Pourquoi notre budget n'est-il que de 50 ms ? En effet, d'autres tâches sont généralement effectuées en plus de la gestion des entrées, et ces tâches occupent une partie du temps disponible pour une réponse acceptable aux entrées. Si une application effectue des tâches par blocs de 50 ms recommandés pendant le temps d'inactivité, cela signifie que l'entrée peut être mise en file d'attente pendant 50 ms maximum si elle se produit pendant l'un de ces blocs de travail. En tenant compte de cela, on peut supposer que seuls les 50 ms restants sont disponibles pour la gestion des entrées. Cet effet est illustré dans le diagramme ci-dessous, qui montre comment les entrées reçues pendant une tâche inactive sont mises en file d'attente, ce qui réduit le temps de traitement disponible :
Animation : produire un frame en 10 ms
Objectifs :
Produisez chaque frame d'une animation en 10 ms ou moins. Techniquement, le budget maximal pour chaque frame est de 16 ms (1 000 ms / 60 frames par seconde ≈ 16 ms), mais les navigateurs ont besoin d'environ 6 ms pour afficher chaque frame. C'est pourquoi la recommandation est de 10 ms par frame.
Visez une fluidité visuelle. Les utilisateurs remarquent les variations de fréquence d'images.
Consignes :
Dans les points de haute pression comme les animations, l'essentiel est de ne rien faire quand vous le pouvez, et le strict minimum quand vous ne le pouvez pas. Dans la mesure du possible, utilisez la réponse de 100 ms pour précalculer les tâches coûteuses afin de maximiser vos chances d'atteindre 60 fps.
Consultez Performances de rendu pour découvrir différentes stratégies d'optimisation des animations.
- Animations visuelles, telles que les entrées et les sorties, les tweens et les indicateurs de chargement.
- Faites défiler l'écran. Cela inclut le défilement rapide, qui se produit lorsque l'utilisateur commence à faire défiler la page, puis la lâche, et que la page continue de défiler.
- Glisser-déposer. Les animations suivent souvent les interactions des utilisateurs, comme le déplacement d'une carte ou le zoom par pincement.
Inactivité : maximiser la durée d'inactivité
Objectif : maximiser le temps d'inactivité pour augmenter les chances que la page réponde à l'intervention de l'utilisateur dans un délai de 50 ms.
Consignes :
Utilisez le temps d'inactivité pour effectuer les tâches différées. Par exemple, pour le chargement initial de la page, chargez le moins de données possible, puis utilisez le temps d'inactivité pour charger le reste.
Effectuez le travail pendant le temps d'inactivité en 50 ms ou moins. Si vous dépassez cette durée, vous risquez d'empêcher l'application de répondre aux entrées utilisateur dans un délai de 50 ms.
Si un utilisateur interagit avec une page pendant une période d'inactivité, l'interaction de l'utilisateur doit toujours être prioritaire et interrompre le travail en période d'inactivité.
Chargement : le contenu doit être fourni et devenir interactif en moins de cinq secondes.
Lorsque les pages se chargent lentement, l'attention des utilisateurs se disperse et ils ont l'impression que la tâche ne fonctionne pas. Les sites qui se chargent rapidement enregistrent des sessions moyennes plus longues, des taux de rebond plus faibles et une meilleure visibilité des annonces.
Objectifs :
Optimisez le chargement rapide en fonction des capacités de l'appareil et du réseau de vos utilisateurs. Actuellement, un bon objectif pour les premiers chargements est de charger la page et de la rendre interactive en 5 secondes ou moins sur les appareils mobiles de milieu de gamme avec des connexions 3G lentes.
Pour les chargements suivants, un bon objectif est de charger la page en moins de deux secondes.
Consignes :
Testez les performances de chargement sur les appareils mobiles et les connexions réseau couramment utilisés par vos utilisateurs. Vous pouvez utiliser le rapport sur l'expérience utilisateur Chrome pour connaître la distribution des connexions de vos utilisateurs. Si les données ne sont pas disponibles pour votre site, le rapport The Mobile Economy 2019 suggère qu'une bonne référence mondiale est un téléphone Android de milieu de gamme, tel qu'un Moto G4, et un réseau 3G lent (défini comme un temps d'aller-retour de 400 ms et une vitesse de transfert de 400 kbit/s). Cette combinaison est disponible sur WebPageTest.
N'oubliez pas que même si l'appareil de votre utilisateur mobile type indique qu'il est connecté à un réseau 2G, 3G ou 4G, la vitesse de connexion effective est souvent beaucoup plus lente en raison de la perte de paquets et de la variance du réseau.
Il n'est pas nécessaire de tout charger en moins de cinq secondes pour donner l'impression d'un chargement complet. Pensez à charger les images de manière différée, à fractionner les bundles JavaScript et à appliquer d'autres optimisations suggérées sur web.dev.
Outils de mesure de RAIL
Il existe quelques outils pour vous aider à automatiser vos mesures RAIL. Le choix de l'une ou l'autre dépend du type d'informations dont vous avez besoin et du type de workflow que vous préférez.
Outils pour les développeurs Chrome
Les outils de développement Chrome fournissent une analyse approfondie de tout ce qui se passe pendant le chargement ou l'exécution de votre page. Consultez Premiers pas avec l'analyse des performances d'exécution pour vous familiariser avec l'UI du panneau Performances.
Les fonctionnalités suivantes des outils de développement sont particulièrement pertinentes :
Limitez votre processeur pour simuler un appareil moins puissant.
Limitez le réseau pour simuler des connexions plus lentes.
Affichez l'activité du thread principal pour voir tous les événements qui se sont produits sur le thread principal pendant l'enregistrement.
Affichez les activités du thread principal dans un tableau pour les trier en fonction de celles qui ont pris le plus de temps.
Analysez les images par seconde (FPS) pour mesurer si vos animations s'exécutent réellement de manière fluide.
Surveillez l'utilisation du processeur, la taille du tas de mémoire JS, les nœuds DOM, les mises en page par seconde et plus encore en temps réel avec le Contrôle des performances.
Visualisez les requêtes réseau qui se sont produites pendant l'enregistrement avec la section Réseau.
Effectuez des captures d'écran pendant l'enregistrement pour reproduire exactement l'aspect de la page pendant son chargement, ou lorsqu'une animation s'est déclenchée, etc.
Afficher les interactions pour identifier rapidement ce qui s'est passé sur une page après qu'un utilisateur a interagi avec elle.
Identifiez les problèmes de performances de défilement en temps réel en mettant en surbrillance la page chaque fois qu'un écouteur potentiellement problématique se déclenche.
Affichez les événements de peinture en temps réel pour identifier les événements de peinture coûteux qui peuvent nuire aux performances de vos animations.
Phare
Lighthouse est disponible dans les outils pour les développeurs Chrome, sur PageSpeed Insights, en tant qu'extension Chrome, en tant que module Node.js et dans WebPageTest. Vous lui fournissez une URL, il simule un appareil de milieu de gamme avec une connexion 3G lente, exécute une série d'audits sur la page, puis vous fournit un rapport sur les performances de chargement, ainsi que des suggestions pour les améliorer.
Les audits suivants sont particulièrement pertinents :
Réponse
Max Potential First Input Delay. Estime le temps que prendra votre application pour répondre à l'intervention de l'utilisateur, en fonction du temps d'inactivité du thread principal.
Total Blocking Time : Mesure le temps total pendant lequel une page est bloquée et ne peut pas répondre aux saisies de l'utilisateur, comme les clics de souris, les appuis sur l'écran ou les frappes au clavier.
Délai avant interactivité. Mesure le moment où un utilisateur peut interagir de manière cohérente avec tous les éléments de la page.
Chargement
N'enregistre pas de service worker contrôlant la page et start_url. Un service worker peut mettre en cache les ressources courantes sur l'appareil d'un utilisateur, ce qui réduit le temps passé à récupérer les ressources sur le réseau.
Le chargement de la page n'est pas suffisamment rapide sur les réseaux mobiles.
Différez le chargement des images hors écran. Différez le chargement des images hors écran jusqu'à ce qu'elles soient nécessaires.
Dimensionnez correctement les images. Ne diffusez pas d'images beaucoup plus grandes que la taille affichée dans la fenêtre d'affichage mobile.
La page n'utilise pas le protocole HTTP/2 pour toutes ses ressources.
Évitez une taille excessive de DOM. Réduisez les octets réseau en n'envoyant que les nœuds DOM nécessaires au rendu de la page.
WebPageTest
WebPageTest est un outil de performances Web qui utilise de vrais navigateurs pour accéder aux pages Web et collecter des métriques de timing. Saisissez une URL sur webpagetest.org/easy pour obtenir un rapport détaillé sur les performances de chargement de la page sur un véritable appareil Moto G4 avec une connexion 3G lente. Vous pouvez également le configurer pour inclure un audit Lighthouse.
Résumé
RAIL est une méthode permettant d'analyser l'expérience utilisateur d'un site Web comme un parcours composé d'interactions distinctes. Comprenez comment les utilisateurs perçoivent votre site afin de définir des objectifs de performances ayant le plus d'impact sur l'expérience utilisateur.
L'internaute avant tout
Répondre aux entrées utilisateur en moins de 100 ms.
Produisez un frame en moins de 10 ms lors de l'animation ou du défilement.
Maximisez le temps d'inactivité du thread principal.
Chargez le contenu interactif en moins de 5 000 ms.