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

Google souhaite que les internautes aient une bonne expérience Web. Il classe donc 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 apparaître plus haut dans les résultats. Mais la façon dont Google mesure cela a toujours été un peu un jeu de devinettes, c'est pourquoi il a introduit Core Web Vitals pour fournir aux propriétaires de sites et aux développeurs une certaine clarté dont ils avaient tant besoin.

Malheureusement, «performance» est un terme fourre-tout pour des dizaines de métriques…

heure du premier octet, démarrage du rendu, utilisation du processeur, taille du tas JavaScript, première peinture riche en contenu, première peinture significative, premier processeur inactif, DOM chargé, page entièrement chargée, heure à des recalculs de style interactifs par seconde etc.

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 concentrez-vous 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 Google Search Console .

La bibliothèque JavaScript web-vitals peut aider à mesurer des mesures plus réalistes provenant 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 à trois. quarts point. Trois visiteurs du site sur quatre connaîtront donc ce niveau de performance.

Les principaux éléments vitaux du Web sont Largest Contentful Paint First Input Delay et Cumulative Layout Shift qui évaluent le chargement, l'interactivité et la stabilité visuelle en conséquence.

Largest Contentful Paint (LCP)

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

Métriques historiques telles que la page load 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 peut apparaître presque instantanément, mais le contenu utilisable chargé par d'autres requêtes Ajax peut prendre beaucoup plus de temps à apparaître.

Largest Contentful Paint (LCP) indique le temps de rendu de la plus grande image ou du plus grand 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 d'arrière-plan chargée à l'aide de la propriété CSS url ()
• éléments de niveau bloc contenant des nœuds de texte.

L'élément le plus grand est déterminé pendant le chargement du contenu et la taille est calculé comme étant ses dimensions visibles dans la fenêtre du navigateur.

LCP peut être affecté par:

• temps de réponse du serveur
• temps de chargement des ressources
• CSS ou JavaScript bloquant le rendu
• temps de traitement de la taille du client [19659020] Des améliorations de LCP peuvent être possibles en:
  1. en utilisant un réseau de distribution de contenu (CDN) pour acheminer les demandes vers des serveurs plus proches
  2. en optimisant la réponse du serveur en minimisant le nombre de processus de rendu coûteux
  3. en minimisant la taille du fichier d'actifs
  4. c

  First Input Delay (FID)

  FID mesure la réactivité – la rapidité avec laquelle une page répond à l'action d'un utilisateur . [19659002] Cette métrique enregistre le temps entre le moment où un utilisateur interagit avec la page (clics, pressions, 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. De plus, il ne mesure que le retard dans le traitement des événements, et non 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 mesure alternative qui peut être calculée sans utilisateur réel contribution. TBT mesure le temps total entre:

  1. le premier Contentful Paint (FCP) – le moment où 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éduisant le temps d'exécution de JavaScript, généralement en différant non -code critique
  2. fractionnement des tâches de longue durée
  3. utilisant web workers pour exécuter des tâches dans un thread d'arrière-plan
  4. chargement de JavaScript tiers à la demande.

  Cumulative Layout Shift ( 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 une publicité ou une image au-dessus de votre position de défilement actuelle comp Letes chargement. Le problème est particulièrement prononcé sur les appareils mobiles et peut vous faire perdre votre place ou cliquer 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 bougera). 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 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: [19659002]

  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. Elle se déplace de 90 pixels verticaux dans la hauteur de la fenêtre 720px, donc sa fraction de distance est 90/720 = 0,125

  Le CLS est donc 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 mauvais. 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 un changement d'interface utilisateur ou un redimensionnement de la fenêtre d'affichage. 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. ouverture d'un menu plein écran à partir d'une icône de hamburger.

  Le panneau Rendering dans Chrome DevTools (menu> Plus d'outils> Rendu) propose une option Layout Shift Regions . 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 panneau Réseau pour ralentir le chargement.

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

  1. en réservant de l'espace pour les images, les vidéos et les éléments iframe en ajoutant des dimensions avec les attributs width et height la propriété CSS aspect-ratio ou l'ancienne astuce de remplissage selon le cas
  2. en évitant 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 ex. inscription à la newsletter et boîtes de notification similaires
  4. utilisant CSS transform et opacity pour des animations moins coûteuses.

  Performance Priorities

  Core Web Vitals évoluera avec le temps mais l'évaluation des mesures LCP, FID et CLS peut aider à identifier les problèmes les plus critiques. Commencez par résoudre les problèmes simples et rapides – ils ont souvent le meilleur retour sur investissement:

  • activez la compression du serveur et HTTP / 2 ou HTTP / 3
  • garantissent que la mise en cache du navigateur est utilisée en définissant les en-têtes d'expiration HTTP
  • précharger actifs tôt
  • concaténer et minimiser CSS et JavaScript
  • supprimer les actifs inutilisés
  • envisager 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 spécialiste CDN 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.