RAIL est un modèle de performances axé sur l'utilisateur qui fournit une structure permettant de 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 désigne quatre aspects distincts du cycle de vie des applications Web: réponse, animation, inactif et chargement. Les utilisateurs ont des attentes de performances différentes pour chacun de ces contextes. Par conséquent, les objectifs de performances sont définis en fonction du contexte et des recherches sur l'expérience utilisateur sur la façon dont les utilisateurs perçoivent les retards.
Centré sur l'utilisateur
Faites de vos utilisateurs le point central de vos efforts en termes de performances. Le tableau ci-dessous décrit les métriques clés de la façon dont les utilisateurs perçoivent les retards de performances:
Perception des retards de performance par les utilisateurs| 0 à 16 ms | Les utilisateurs sont particulièrement doués pour suivre les mouvements et ils n'apprécient pas lorsque les animations ne sont pas fluides. Il perçoit les animations comme étant fluides à condition que 60 nouvelles images soient affichées chaque seconde. Cela représente 16 ms par frame, y compris le temps nécessaire au navigateur pour afficher le nouveau cadre à l'écran, ce qui laisse environ 10 ms à l'application pour produire un frame. |
| 0 à 100 ms | Répondez aux actions des utilisateurs dans ce délai et ils ont l'impression que le résultat est immédiat. Plus longtemps, et le lien entre action et réaction est rompu. |
| 100 à 1 000 ms | Dans cette fenêtre, les choses semblent faire partie d'une progression naturelle et continue des tâches. Pour la plupart des internautes, charger des pages ou changer d'affichage représente une tâche spécifique. |
| 1 000 ms ou plus | Au-delà de 1 000 millisecondes (1 seconde), les utilisateurs ne se concentrent plus sur la tâche qu'ils sont en train d'effectuer. |
| 10 000 ms ou plus | Au-delà de 10 000 millisecondes (10 secondes), les utilisateurs sont frustrés et risquent d'abandonner des tâches. Ils ne reviendront peut-être pas plus tard. |
Objectifs et consignes
Dans le contexte du RAIL, les termes objectifs et directives ont une signification spécifique:
Objectifs : principales métriques de performances liées à l'expérience utilisateur. Par exemple, appuyez pour peindre en moins de 100 millisecondes. La perception humaine étant relativement constante, il est peu probable que ces objectifs changent de temps.
Consignes. Recommandations pour vous aider à atteindre vos objectifs. Celles-ci peuvent être spécifiques aux conditions matérielles et de connexion réseau actuelles, et peuvent donc changer au fil du temps.
Réponse: traiter les événements en moins de 50 ms
Objectif: Effectuer une transition déclenchée par une entrée utilisateur dans un délai de 100 ms afin que les utilisateurs aient l'impression que les interactions sont instantanées.
Consignes:
Pour garantir une réponse visible en 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, telles que 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 déplacements tactiles ni aux défilements.
Bien que cela puisse sembler contre-intuitif, ce n'est pas toujours le bon appel pour répondre immédiatement à l'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, faites le travail en arrière-plan.
Pour les actions qui prennent plus de 50 ms, envoyez toujours des commentaires.
50 ms ou 100 ms ?
L'objectif est de répondre aux entrées 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 cette tâche occupe une partie du temps disponible pour obtenir une réponse d'entrée acceptable. Si une application s'exécute dans les fragments de 50 ms recommandés pendant le temps d'inactivité, cela signifie que les entrées peuvent être mises en file d'attente jusqu'à 50 ms si elles se produisent au cours de l'un de ces fragments de tâche. Ainsi, on peut supposer que seules les 50 ms restantes sont disponibles pour le traitement réel des entrées. Cet effet est illustré dans le schéma 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: produit un frame en 10 ms
Objectifs:
Créez chaque image d'une animation en 10 ms maximum. Techniquement, le budget maximal pour chaque image est de 16 ms (1 000 ms / 60 images par seconde environ 16 ms), mais les navigateurs ont besoin d'environ 6 ms pour afficher chaque image, d'où la limite de 10 ms par image.
Optez pour la fluidité visuelle. Les utilisateurs s'aperçoivent lorsque la fréquence d'images varie.
Consignes:
Pour les points à forte pression, comme les animations, l'essentiel est de ne rien faire là où vous le pouvez, et le minimum absolu où vous ne pouvez pas. Dans la mesure du possible, utilisez la réponse de 100 ms pour précalculer les tâches coûteuses afin d'optimiser vos chances d'atteindre 60 FPS.
Consultez la section Performances d'affichage 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 glissement d'un geste vif, c'est-à-dire lorsque l'utilisateur commence à faire défiler l'écran, puis abandonne et continue à faire défiler la page.
- Déplacement Les animations suivent souvent les interactions de l'utilisateur, telles que le panoramique d'une carte ou le pincement pour zoomer.
Inactif: optimiser la durée 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 terminer 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 les tâches en cas d'inactivité en 50 ms maximum. et vous risquez d'interférer avec la capacité de l'application à répondre à l'entrée utilisateur dans un délai de 50 ms.
Si un utilisateur interagit avec une page pendant son travail d'inactivité, cette interaction doit toujours avoir la priorité la plus élevée et interrompre cette tâche.
Chargement: diffusez du contenu et devenez interactif en moins de 5 secondes
Lorsque les pages se chargent lentement, l'attention des utilisateurs s'éloigne, et ils perçoivent la tâche comme défectueuse. Les sites qui se chargent rapidement présentent des sessions moyennes plus longues, des taux de rebond plus faibles et une meilleure visibilité des annonces.
Objectifs:
Optimisez vos performances de chargement en fonction des capacités de l'appareil et du réseau de vos utilisateurs. Actuellement, pour les premiers chargements, il est recommandé de charger la page et d'être interactif en cinq secondes maximum sur les appareils mobiles de milieu de gamme avec des connexions 3G lentes.
Pour les chargements suivants, nous vous recommandons de charger la page en moins de deux secondes.
Consignes:
Testez vos performances de charge sur les appareils mobiles et les connexions réseau courants. Vous pouvez utiliser le rapport d'expérience utilisateur Chrome pour connaître la distribution de la connexion de vos utilisateurs. Si les données ne sont pas disponibles pour votre site, The Mobile Economy 2019 suggère qu'un téléphone Android milieu de gamme, tel qu'un Moto G4, et un réseau 3G lent (défini comme un DAR de 400 ms et une vitesse de transfert de 400 kbit/s) constituent un bon point de référence international. Cette combinaison est disponible sur WebPageTest.
Gardez à l'esprit que, bien que l'appareil de votre utilisateur type puisse affirmer qu'il utilise une connexion 2G, 3G ou 4G, en réalité, la vitesse de connexion réelle est souvent considérablement 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 5 secondes pour avoir l'impression que la charge est complète. Envisagez d'utiliser des images à chargement différé, des bundles JavaScript de division du code et d'autres optimisations suggérées sur web.dev.
Outils de mesure du RAIL
Plusieurs outils sont à votre disposition pour vous aider à automatiser vos mesures RAIL. La méthode à utiliser 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 la section 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.
Affichez 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 une table pour trier les activités en fonction de celles qui prennent le plus de temps.
Analysez les images par seconde (FPS) pour mesurer le bon fonctionnement de vos animations.
Surveillez en temps réel 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 avec Performance Monitor.
Visualisez les requêtes réseau qui se sont produites pendant l'enregistrement dans la section Réseau.
Faites des captures d'écran pendant l'enregistrement pour lire exactement l'aspect de la page lors du chargement de la page, le déclenchement d'une animation, etc.
Affichez 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 susceptibles de 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 attribuez une URL, simule un appareil de milieu de gamme avec une connexion 3G lente, exécute une série d'audits sur la page, puis génère un rapport sur les performances de chargement, ainsi que des suggestions d'amélioration.
Les audits suivants sont particulièrement pertinents:
Response (Réponse)
Max Potential First Input Delay (Max Potential First Input Delay). Estime le temps nécessaire à votre application pour répondre à l'entrée 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 (Temps de blocage total) Mesure la durée totale pendant laquelle une page est bloquée pour répondre aux entrées utilisateur, telles que les clics de souris, les appuis sur l'écran ou les pressions au clavier.
Time To Interactive. Mesure à quel moment un utilisateur peut interagir de façon 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 des ressources communes sur l'appareil d'un utilisateur, ce qui réduit le temps consacré à la récupération des ressources sur le réseau.
Le chargement de la page n'est pas assez rapide sur les réseaux mobiles.
Différez 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 pour mobile.
N'utilise pas le protocole HTTP/2 pour toutes ses ressources.
Évitez une taille de DOM excessive. Réduisez le nombre d'octets réseau en n'expédiant que les nœuds DOM nécessaires à l'affichage de la page.
WebPageTest
WebPageTest est un outil de mesure des performances Web qui utilise de vrais navigateurs pour accéder aux pages Web et collecter des métriques temporelles. Saisissez une URL sur la page webpagetest.org/easy pour obtenir un rapport détaillé sur les performances de chargement de la page sur un véritable appareil Moto G4 dont la connexion 3G est lente. Vous pouvez également le configurer pour inclure un audit Lighthouse.
Résumé
RAIL permet de considérer l'expérience utilisateur d'un site Web comme un parcours composé d'interactions distinctes. Découvrez 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épond aux entrées utilisateur en moins de 100 ms.
Permet d'afficher un cadre en moins de 10 ms lors d'une animation ou d'un défilement.
Maximiser le temps d'inactivité du thread principal.
Chargez du contenu interactif en moins de 5 000 ms.