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 de l'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 l'acronyme de 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 UX sur la façon dont les utilisateurs perçoivent les retards.
Centré sur l'utilisateur
Placez les utilisateurs au cœur de vos efforts d'optimisation des performances. Le tableau ci-dessous décrit les métriques clés de la perception des retards de performances par les utilisateurs :
Perception des retards de performances par l'utilisateur| 0 à 16 ms | Les utilisateurs sont particulièrement doués pour suivre les mouvements et n'apprécient pas que les animations ne soient pas fluides. Ils perçoivent les animations comme fluides tant que 60 nouvelles images sont affichées chaque seconde. Cela correspond à 16 ms par image, y compris le temps nécessaire au navigateur pour afficher la nouvelle image à l'écran, ce qui laisse environ 10 ms à une application pour produire une image. |
| 0 à 100 ms | Si vous répondez aux actions des utilisateurs dans ce délai, ils auront 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 du Web, charger des pages ou changer de vue représente 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'ils reviennent plus tard, ou non. |
Objectifs et consignes
Dans le contexte de RAIL, les termes objectifs et consignes ont une signification spécifique :
Objectifs : métriques de performances clés liées à l'expérience utilisateur. Par exemple, appuyez pour peindre en moins de 100 millisecondes. Comme 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 entrée 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 un délai de 100 ms, traitez les événements d'entrée utilisateur dans un délai de 50 ms. Cela s'applique à la plupart des entrées, comme les clics sur des boutons, l'activation/la désactivation des commandes de formulaire ou le démarrage d'animations. Cela ne s'applique pas aux glissements ou aux défilements tactiles.
Même si cela peut sembler contre-intuitif, il n'est pas toujours judicieux de répondre immédiatement à une entrée 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 les tâches 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 à une entrée en moins de 100 ms. Alors, 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 prennent 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 (durée recommandée) pendant les périodes 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 le traitement réel des entrées. Cet effet est illustré dans le diagramme ci-dessous, qui montre comment les entrées reçues lors d'une tâche inactive sont mises en file d'attente, ce qui réduit le temps de traitement disponible :
Animation : produire une image en 10 ms
Objectifs :
Produisez chaque image d'une animation en 10 ms ou moins. Techniquement, le budget maximal pour chaque frame est de 16 ms (1 000 ms/60 images par seconde ≈ 16 ms), mais les navigateurs ont besoin d'environ 6 ms pour afficher chaque frame, d'où la recommandation de 10 ms par frame.
Visez la fluidité visuelle. Les utilisateurs remarquent les variations de fréquence d'images.
Consignes :
Dans les points de pression élevés tels que les animations, l'essentiel est de ne rien faire là où vous le pouvez, et le strict minimum là où 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 interpolations et les indicateurs de chargement.
- Défilement. Cela inclut le balayage, qui se produit lorsque l'utilisateur commence à faire défiler la page, puis lâche prise, et que la page continue de défiler.
- Glissement. Les animations suivent souvent les interactions de l'utilisateur, comme le déplacement d'une carte ou le zoom par pincement.
Inactif : maximiser le temps d'inactivité
Objectif : maximiser le temps d'inactivité pour augmenter les chances que la page réponde aux entrées 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 les temps d'inactivité en 50 ms ou moins. Si vous dépassez cette durée, vous risquez d'interférer avec la capacité de l'application à répondre aux entrées de l'utilisateur dans un délai de 50 ms.
Si un utilisateur interagit avec une page pendant une tâche en temps d'inactivité, l'interaction de l'utilisateur doit toujours avoir la priorité absolue et interrompre la tâche en temps d'inactivité.
Chargement : diffuser du contenu et devenir interactif en moins de cinq secondes
Lorsque les pages se chargent lentement, l'attention de l'utilisateur se disperse et il a l'impression que la tâche est interrompue. 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 les performances de 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 cinq 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 de Chrome pour connaître la répartition des connexions de vos utilisateurs. Si les données ne sont pas disponibles pour votre site, The Mobile Economy 2019 suggère qu'un bon point de référence global 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 RTT 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.
Vous n'avez pas besoin de tout charger en moins de cinq secondes pour donner l'impression d'un chargement complet. Envisagez d'utiliser le chargement différé des images, la division du code des bundles JavaScript et 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 pour les développeurs 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'interface utilisateur du panneau Performances.
Les fonctionnalités des outils de développement suivantes sont particulièrement pertinentes :
Limitez votre processeur pour simuler un appareil moins puissant.
Limitez le réseau pour simuler des connexions plus lentes.
Afficher l'activité du thread principal pour afficher 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 le nombre d'images par seconde (FPS) pour mesurer si vos animations s'exécutent 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 moniteur de performances.
Visualisez les requêtes réseau qui se sont produites pendant l'enregistrement à l'aide de la section Réseau.
Effectuez des captures d'écran pendant l'enregistrement pour voir exactement à quoi ressemblait la page pendant son chargement, ou lorsqu'une animation s'est déclenchée, etc.
Affichez les interactions pour identifier rapidement ce qui s'est passé sur une page après qu'un utilisateur a interagi avec elle.
Détectez 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 d'amélioration.
Les audits suivants sont particulièrement pertinents :
Réponse
Délai maximal potentiel avant première interaction. Estime le temps nécessaire à votre application pour répondre aux entrées utilisateur, en fonction du temps d'inactivité du thread principal.
N'utilise pas d'écouteurs passifs pour améliorer les performances de défilement.
Total Blocking Time. Mesure la durée totale pendant laquelle une page est bloquée et ne répond pas aux entrées utilisateur, telles que les clics de souris, les appuis sur l'écran ou les pressions sur le clavier.
Time to Interactive. 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 qui contrôle 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 assez rapide sur les réseaux mobiles.
Différer les 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 dont la taille est nettement supérieure à celle affichée dans la fenêtre d'affichage mobile.
Évitez une taille de DOM excessive. Réduisez le nombre d'octets réseau en n'envoyant que les nœuds DOM nécessaires à l'affichage 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 temps. Saisissez une URL sur webpagetest.org/easy pour obtenir un rapport détaillé sur les performances de chargement de la page sur un appareil Moto G4 réel avec une connexion 3G lente. Vous pouvez également le configurer pour inclure un audit Lighthouse.
Résumé
RAIL est un objectif permettant d'examiner 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épondez 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.
Charger du contenu interactif en moins de 5 000 ms.