Comment mesurer la vitesse du site à l’aide du modèle de performance du rail

Comment mesurez – vous le rendement du site? Il y a beaucoup d’informations en ligne sur la façon d’optimiser votre site, mais comment savez – vous vraiment que vous faites assez bien? Afin d’aider les développeurs à mesurer leurs efforts d’optimisation et de leur rappeler de placer les utilisateurs au centre de leur histoire de performance, plusieurs Google ont développé des modèles de rail. Rail est un modèle de performance axé sur l’utilisateur qui divise l’expérience Web de l’utilisateur en quatre opérations clés. Encouragez les développeurs à considérer la performance web dans son ensemble, plutôt que de vous demander « qu’est – ce que la lenteur signifie? » Au lieu de cela, demandez: « que ressentent les utilisateurs lorsqu’ils interagissent avec ce que nous construisons? »
Dans cet article, nous explorerons ce qu’est le rail, les lignes directrices du modèle qui peuvent vous aider à déterminer quand « faire assez » et quels outils vous pouvez utiliser sur votre site Web pour mesurer le rail. Quel est le modèle ferroviaire? Lorsque vous chargez une page Web, de nombreux problèmes techniques se produisent dans les coulisses. À l’arrière – plan, le site demande et reçoit des fichiers et des ressources, tandis qu’à l’avant – plan, le navigateur charge du texte, des images et d’autres médias. Lorsque tout cela se produit, l’utilisateur attend que la page soit chargée pour commencer à interagir avec la page, ce qui est bien si vous avez optimisé la vitesse de la page. Le problème est que les développeurs oublient souvent ce qui se passe lorsque la page est chargée.
Selon le Guide de base Web de Google, les utilisateurs passent la plus grande partie de leur temps à attendre que le site réponde à leurs commentaires (comme les clics, les clics et les commutateurs) sans avoir à attendre que le site soit chargé. Ainsi, bien que votre site puisse être chargé à la vitesse de la lumière, si l’utilisateur clique sur le lien dans la navigation et prend deux secondes pour enregistrer l’entrée, cela signifie squatter. Le modèle Rail tient compte de ce fait en divisant l’expérience utilisateur du site en quatre actions clés: réponse, animation
Action, ralenti et chargement. Photo: Paul Ireland. Chaque action ferroviaire a ses propres objectifs de rendement, qui sont fondés sur des seuils perçus par l’homme et dont nous discuterons bientôt. L’idée qui sous – tend le modèle est que si vous Optimisez votre site Web en fonction de chacun de ces domaines et offrez une expérience Web continue et rapide, vos utilisateurs seront heureux. Avant d’approfondir le Code ferroviaire et ses paramètres de référence, il est important de comprendre d’abord les seuils perçus par l’homme. Lorsque vous Optimisez votre site pour le rendre plus rapide, considérez – vous ce que les utilisateurs ressentent lorsqu’ils naviguent sur votre site? Peut – être pas. Cependant, cette perception du rendement du site est un élément essentiel du rail.
La recherche de Jakob Nielsen sur le temps de réponse est une recherche universitaire de référence sur la perception humaine de la performance du réseau depuis sa publication en 1993. En 2015, les googlers Paul Irish et Paul Lewis ont présenté leur modèle de chemin de fer en modifiant les résultats originaux de Nielsen pour ajouter un temps de réponse supplémentaire (0 à 16 MS) à l’animation. De 0 à 16 MS: les gens sont très bons pour suivre les mouvements et n’aiment pas les situations où l’animation a un taux de trame variable ou s’arrête trop. L’animation est considérée comme lisse parce qu’elle rend 60 nouvelles images par seconde. 16 MS par image. 0 à 100 MS: l’utilisateur pense que la réponse à son action en moins de 100 MS est instantanée. Une fois de plus, le lien entre l’action et la réaction a été rompu. 100 à 300 MS: l’utilisateur sentira un léger retard. 300 à 1000 MS: dans cette fenêtre, l’utilisateur a l’impression que quelque chose se passe, par exemple, la page est chargée et l’activité est en cours. 1000 MS ou plus: plus d’une seconde, l’utilisateur ne peut pas se concentrer
La deuxième fois, mais ce faisant, vous arrêtez de répondre au premier clic… C’est exactement ce que Rail veut éviter. Objectif: traiter les événements dans les 50 millisecondes. Google Guide: les sites Web doivent traiter les actions \/ entrées de l’utilisateur dans les 50 millisecondes pour s’assurer qu’une réponse visible est faite dans les 100 millisecondes. Pour les actions qui prennent plus de 50 millisecondes à compléter, toujours fournir une rétroaction, comme afficher un indicateur de charge ou changer la couleur du Focus.
L’animation est devenue si courante dans la conception web que les utilisateurs s’attendent à ce que l’interaction soit si fluide qu’ils le remarqueront immédiatement lorsque le taux de trame est encore un peu plus faible. L’animation comprend: l’animation visuelle. Cela comprend l’animation d’entrée et de sortie et l’indicateur de charge. Roulez. Cela inclut l’utilisation de la barre de défilement, mais aussi le démarrage, c’est – à – dire que l’utilisateur commence à défiler, puis laisse tomber, et la page continue à défiler. Drag Comment zoomer sur une carte ou pincer. Objectif: générer un cadre en 10 Ms.
Google Guide: pour faire une animation correctement, chaque image de l’animation doit être terminée en 16 millisecondes pour atteindre 60 images par seconde (c. – à – D. 1 seconde ÷ 60 = 16,6 millisecondes). Le budget maximum par image est de 16 MS, mais le navigateur a besoin d’environ 6 ms pour rendre chaque image. Le temps libre est ce qui se passe dans les coulisses après le téléchargement initial du site. Comme je l’a i mentionné dans un récent article sur les techniques de pré – navigation, le temps libre offre une occasion idéale de précharger, de pré – lire et de pré – Connecter les ressources.
Objectif: maximiser les temps d’arrêt afin d’augmenter les chances que les pages répondent aux interactions des utilisateurs en 50 millisecondes.
A lors du chargement initial, n’utilisez que les éléments les plus critiques de la page et utilisez votre temps libre pour tout le reste. Google recommande de diviser les travaux retardés pendant les temps d’arrêt en blocs de 50 millisecondes afin que votre site puisse répondre dans 100 fenêtres de réponse. Si l’utilisateur interagit avec la page pendant son temps libre, son interaction devrait avoir la priorité et arrêter le temps libre. La charge de travail consiste à amener rapidement l’utilisateur dans la première peinture importante. Cela signifie qu’il faut moins d’une seconde pour charger la page. Plus votre page est chargée rapidement, moins les utilisateurs sautent, moins ils sont susceptibles de perdre le focus et moins ils sont susceptibles de penser que l’activité qu’ils essaient de terminer a été interrompue. Selon Google, il n’est pas surprenant que les sites à chargement rapide aient en moyenne des sessions plus longues, des taux de sauts plus faibles et une plus grande visibilité publicitaire. Objectif: terminer la première peinture significative en 1 seconde et l’interaction en 5 secondes. Google Guide: optimiser la vitesse des pages par rapport aux appareils et aux connexions réseau que les utilisateurs utilisent lorsqu’ils visitent un site Web. Concentrez – vous sur l’optimisation des chemins de rendu critiques du site pour déverrouiller le rendu et profiter des temps d’arrêt. Google recommande d’utiliser des appareils mobiles de moyenne portée avec des connexions 3G lentes pour charger des pages et interagir en 5 secondes ou moins. Pour les charges ultérieures, visez pendant 2 secondes ou moins. Outils de mesure du rail les objectifs fixés par le rail semblent élevés, mais il n’est pas difficile de les mesurer et de les surveiller à l’aide de trois outils gratuits (chrome devtools, Lighthouse et webgettest). Outils de développement Chrome: outils de développement intégrés pour Chrome t