Catégories
Astuces et Design

Core Web Vitals: Guide des mesures de performances Web de Google

Google veut que les gens aient une bonne expérience Web, c'est pourquoi il classe les sites rapides plus haut dans les résultats de recherche. Bien sûr, c'est une simplification grossière, mais en supposant que vous comparez deux sites avec un contenu et des audiences similaires, le plus rapide devrait semblent plus élevés dans les résultats. Mais comment Google mesure cela a toujours été un peu un jeu de devinettes, il a donc introduit Core Web Vitals pour fournir aux propriétaires de sites et aux développeurs une clarté indispensable.

Malheureusement, "performance" est un terme fourre-tout pour des dizaines d'indicateurs…

heure jusqu'au premier octet, démarrage du rendu, utilisation du processeur, taille du tas JavaScript, première peinture pleine de contenu, première peinture significative, premier processeur inactif, DOM chargé, page entièrement chargée, temps d'interactivité, recalculs de style par seconde, et plus.

Différents outils renvoient différents ensembles de résultats et il peut être difficile de savoir par où commencer.

L'initiative Web Vitals de Google vise à simplifier l'évaluation des performances et à vous aider à vous concentrer sur les améliorations les plus importantes. Les Core Web Vitals sont des mesures de performances critiques qui reflètent les expériences utilisateur réelles. Certains sont signalés par le panneau Lighthouse dans Chrome DevTools, PageSpeed ​​Insights et la console de recherche Google.

La bibliothèque JavaScript Web-Vitals peut aider à mesurer des mesures plus réalistes à partir d'utilisateurs réels accédant à votre site. Les résultats peuvent être publiés sur Google Analytics ou d'autres points de terminaison pour une analyse plus approfondie.

Google conseille d'utiliser le 75e centile, c'est-à-dire d'enregistrer plusieurs résultats pour la même métrique, de les trier du meilleur au pire, puis d'analyser le chiffre aux trois quarts. Trois visiteurs sur quatre connaîtront donc ce niveau de performance.

Les Core Web Vitals actuels sont La plus grande peinture riche en contenu, Premier délai d'entrée, et Décalage cumulatif de la disposition qui évaluent le chargement, l'interactivité et la stabilité visuelle en conséquence.

La plus grande peinture de contenu (LCP)

LCP mesure les performances de chargement – à quelle vitesse le contenu apparaît.

Statistiques historiques telles que le chargement de la page et DOMContentLoaded ont eu du mal à cet égard car ils ne sont pas toujours représentatifs de l'expérience utilisateur. Par exemple, un écran de démarrage pourrait apparaître presque instantanément, mais le contenu utilisable chargé par d'autres requêtes Ajax pourrait prendre beaucoup plus de temps à apparaître.

Largest Contentful Paint (LCP) indique le temps de rendu de la plus grande image ou bloc de texte visible dans la fenêtre. Un temps inférieur à 2,5 secondes est considéré comme bon et tout ce qui dépasse 4,0 secondes est considéré comme médiocre.

Les types d'éléments considérés dans LCP sont:

  • éléments
  • éléments à l'intérieur d'un
  • l'image d'affiche d'un élément
  • un élément avec une image de fond chargée en utilisant le CSS url() propriété
  • éléments de niveau bloc contenant des nœuds de texte.

L'élément le plus grand est déterminé lors du chargement du contenu et la taille est calculée pour correspondre à ses dimensions visibles dans la fenêtre du navigateur.

Le LCP peut être affecté par:

  • temps de réponse du serveur
  • temps de chargement des ressources
  • CSS ou JavaScript bloquant le rendu
  • délais de traitement de la taille du client

Des améliorations LCP peuvent être possibles en:

  1. en utilisant un réseau de diffusion de contenu (CDN) pour acheminer les demandes vers des serveurs plus proches
  2. optimisation de la réponse du serveur en minimisant le nombre de processus de rendu coûteux
  3. minimiser la taille des fichiers des actifs
  4. mettre en cache les ressources localement, et peut-être utiliser un service worker pour renvoyer d'abord la version locale.

Premier délai d'entrée (FID)

Le FID mesure la réactivité – la rapidité avec laquelle une page répond à l'action d'un utilisateur.

Cette métrique enregistre le temps entre le moment où un utilisateur interagit avec la page (clics, pressions, pressions sur les touches, etc.) jusqu'au moment où le navigateur commence à traiter ce gestionnaire d'événements. Un retard de moins de 100 ms est considéré comme bon et tout ce qui dépasse 300 ms est considéré comme médiocre.

Le FID ne peut être mesuré avec précision que lorsqu'une application est servie à un utilisateur réel. En outre, il ne mesure que le retard dans le traitement des événements, pas le temps nécessaire pour exécuter un gestionnaire ou mettre à jour l'interface utilisateur.

Google et divers outils utilisent donc le temps de blocage total (TBT) comme une mesure alternative qui peut être calculée sans intervention réelle de l'utilisateur. Le TBT mesure le temps total entre:

  1. la First Contentful Paint (FCP) – l'heure à laquelle une partie du contenu de la page a été rendue, et
  2. le Time to Interactive (TTI) – le moment où la page est capable de répondre de manière fiable aux entrées de l'utilisateur (aucune tâche longue n'est en cours d'exécution et pas plus de deux requêtes GET doivent encore être résolues).

Des améliorations FID / TBT peuvent être possibles en:

  1. réduire le temps d'exécution de JavaScript, généralement en différant le code non critique
  2. interrompre les tâches de longue durée
  3. utilisation de web workers pour exécuter des tâches dans un thread d'arrière-plan
  4. chargement de JavaScript tiers à la demande.

Décalage cumulatif de la disposition (CLS)

CLS mesure la stabilité visuelle – le mouvement inattendu du contenu lors de la visualisation d'une page.

CLS évalue ces situations ennuyeuses lorsque le contenu se déplace sans avertissement – généralement lorsque le DOM change après qu'une publicité ou une image au-dessus de votre position de défilement actuelle termine le chargement. Le problème est particulièrement prononcé sur les appareils mobiles et peut vous faire perdre votre place ou appuyer sur le mauvais lien.

CLS est calculé en multipliant:

  1. La fraction d'impact: la surface totale des éléments instables dans la fenêtre (ceux qui vont bouger). Une fraction d'impact de 0,5 indique que les éléments totalisant la moitié de la fenêtre seront déplacés.
  2. La fraction de distance: la plus grande distance déplacée par un élément unique dans la fenêtre. Une fraction de distance de 0,25 indique qu'au moins un élément s'est déplacé d'un quart de la fenêtre (horizontalement ou verticalement).

Prenons l'exemple suivant qui charge une publicité peu de temps après le rendu du logo, du menu et de l'image du héros:

Exemple CLS

Le logo et le menu ne bougent pas – ce sont des éléments stables. La publicité est ajoutée au DOM et sa position de départ ne change pas, elle est donc également stable. Cependant, l'image du héros se déplacera:

  1. Le héros mesure 360 ​​x 510 pixels dans une fenêtre de 360 ​​x 720. Sa fraction d'impact est donc (360 x 510) / (360 x 720) = 0,71
  2. Il se déplace de 90 pixels verticaux dans la hauteur de la fenêtre de 720 pixels. La fraction de distance est donc de 90/720 = 0,125

Le CLS est donc de 0,71 x 0,125 = 0,089

Un score CLS inférieur à 0,1 est considéré comme bon et tout ce qui dépasse 0,25 est considéré comme médiocre. Dans ce cas, le CLS est juste dans la plage acceptée car, bien qu'une grande zone soit affectée, elle est déplacée sur une distance relativement petite. Une publicité plus grande nécessiterait cependant une attention supplémentaire.

L'algorithme CLS n'enregistre pas le décalage de mise en page pendant 500 ms après toute interaction de l'utilisateur qui pourrait déclencher une modification de l'interface utilisateur ou un redimensionnement de la fenêtre. Par conséquent, votre page ne sera pas pénalisée pour les mises à jour d'interface, les transitions et les animations nécessaires au fonctionnement, par ex. ouvrir un menu plein écran à partir d'une icône de hamburger.

le Le rendu panneau dans Chrome DevTools (menu> Plus d'outils> Rendu) fournit un Régions de décalage de disposition option. Cochez la case et actualisez la page – les changements de disposition sont surlignés en bleu. Vous pouvez également modifier la vitesse du réseau dans le Réseau panneau pour ralentir le chargement.

Des améliorations FID / TBT peuvent être possibles en:

  1. réserver de l'espace pour les images, les vidéos et les éléments iframe en ajoutant des dimensions avec width et height attributs, le CSS aspect-ratio propriété, ou l'ancienne astuce de remplissage selon le cas
  2. éviter FOUT (Flash of Unstyled Text) et FOIT (Flash of Invisible Text) lors du chargement de polices Web. Le préchargement ou l'utilisation de polices de remplacement de taille similaire aidera
  3. ne pas insérer d'éléments DOM au-dessus du contenu existant lors du chargement initial de la page, par exemple inscription à la newsletter et boîtes de notification similaires
  4. en utilisant CSS transform et opacity pour des animations moins coûteuses.

Priorités de performance

Core Web Vitals évoluera au fil du temps, mais l'évaluation des métriques LCP, FID et CLS peut aider à identifier les problèmes les plus critiques. Abordez d'abord les problèmes simples et rapides – ils offrent souvent le meilleur retour sur investissement:

  • activer la compression du serveur et HTTP / 2 ou HTTP / 3
  • s'assurer que la mise en cache du navigateur est utilisée en définissant les en-têtes d'expiration HTTP
  • précharger les actifs tôt
  • concaténer et minimiser CSS et JavaScript
  • supprimer les éléments inutilisés
  • envisagez d'utiliser un CDN ou un meilleur hébergement
  • utiliser des tailles et des formats d'image appropriés
  • optimiser la taille des fichiers image et vidéo (un CDN spécialisé peut vous aider)

Le livre SitePoint Jump Start Web Performance fournit des dizaines de conseils pour améliorer la vitesse du site, réduire les coûts et satisfaire les utilisateurs.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *