Identifier des opportunités d'améliorer l'expérience utilisateur avec les outils Web de Chrome
Date de publication : 11 mai 2021
Aujourd'hui, nous allons vous présenter de nouvelles fonctionnalités d'outils dans Lighthouse, PageSpeed et DevTools pour vous aider à identifier comment améliorer les Web Vitals de votre site.
Pour rappel, Lighthouse est un outil Open Source automatisé qui permet d'améliorer la qualité des pages Web. Vous le trouverez dans la suite d'outils de débogage Chrome DevTools. Vous pouvez l'exécuter sur n'importe quelle page Web, qu'elle soit publique ou qu'elle nécessite une authentification. Vous pouvez également trouver Lighthouse dans PageSpeed Insights, CI et WebPageTest.
Lighthouse 7.x inclut de nouvelles fonctionnalités telles que les captures d'écran d'éléments, pour une inspection visuelle plus facile des parties de votre UI qui ont un impact sur les métriques d'expérience utilisateur (par exemple, les nœuds qui contribuent au décalage de mise en page).
Nous avons également ajouté la prise en charge des captures d'écran d'éléments dans PageSpeed Insights, ce qui permet d'identifier plus facilement les problèmes lors des exécutions ponctuelles des performances des pages.
Mesurer les Core Web Vitals
Lighthouse peut mesurer de manière synthétique les métriques Core Web Vitals, y compris le Largest Contentful Paint, le Cumulative Layout Shift et le Total Blocking Time (un proxy de laboratoire pour le First Input Delay). Ces métriques reflètent le chargement, la stabilité de la mise en page et la préparation à l'interaction. D'autres métriques, telles que First Contentful Paint, mises en avant dans l'avenir des Core Web Vitals, sont également disponibles.
La section "Métriques" du rapport Lighthouse inclut les versions de laboratoire de ces métriques. Vous pouvez l'utiliser comme vue récapitulative des aspects de l'expérience utilisateur qui nécessitent votre attention.
Les métriques de champ, telles que celles du rapport UX Chrome ou de la surveillance des utilisateurs réels, ne présentent pas cette limitation et constituent un complément précieux aux données de laboratoire, car elles reflètent l'expérience des utilisateurs réels. Les données de terrain ne peuvent pas fournir les types d'informations de diagnostic que vous obtenez en laboratoire. Les deux sont donc complémentaires.
Identifier les points à améliorer concernant les métriques Web Vitals
Identifier l'élément Largest Contentful Paint
Le LCP est une mesure de l'expérience de chargement perçue. Il marque le moment, lors du chargement de la page, où le contenu principal (ou "le plus grand") a été chargé et est visible par l'utilisateur.
Lighthouse propose un audit "Élément Largest Contentful Paint" qui identifie l'élément Largest Contentful Paint. Si vous pointez sur l'élément, il sera mis en surbrillance dans la fenêtre principale du navigateur.
Si cet élément est une image, cette information est un indice utile qui peut vous inciter à optimiser le chargement de cette image. Lighthouse inclut un certain nombre d'audits d'optimisation des images pour vous aider à déterminer si vos images pourraient être mieux compressées, redimensionnées ou diffusées dans un format d'image moderne plus optimal.
Le favori intelligent LCP d'Annie Sullivan peut également vous être utile pour identifier rapidement l'élément LCP à l'aide d'un rectangle rouge en un seul clic.
Précharger les images découvertes tardivement pour améliorer le LCP
Pour améliorer le Largest Contentful Paint, préchargez vos images héros critiques si elles sont découvertes tardivement par le navigateur. Une découverte tardive peut se produire si un bundle JavaScript doit être chargé avant que l'image ne soit détectable.
Voici quelques questions fréquentes sur le préchargement des images LCP, qu'il peut être utile d'aborder brièvement.
Pouvez-vous précharger des images responsives ? Oui.
Supposons que nous ayons une image héros responsive, comme spécifié à l'aide de srcset et sizes ci-dessous :
<img src="lighthouse.jpg"
srcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">
Grâce aux attributs imagesrcset et imagesizes ajoutés à l'attribut link, nous pouvons précharger une image responsive en utilisant la même logique de sélection d'image que celle utilisée par srcset et sizes :
<link rel="preload" as="image" href="lighthouse.jpg"
imagesrcset="lighthouse_400px.jpg 400w,
lighthouse_800px.jpg 800w,
lighthouse_1600px.jpg 1600w"
imagesizes="50vw">
L'audit mettra-t-il également en évidence les opportunités de préchargement si l'image LCP est définie via un arrière-plan CSS ? Oui.
Toute image signalée comme image LCP, que ce soit via un arrière-plan CSS ou <img>, est un candidat si elle est découverte à une profondeur de cascade de trois ou plus.
Chargement différé des images hors écran et évitement de cette pratique pour le LCP
Les images hors écran qui ne sont pas essentielles à l'expérience utilisateur initiale peuvent être chargées de manière différée. Cette technique consiste à différer le téléchargement d'une image jusqu'à ce qu'un utilisateur la fasse défiler, ce qui peut réduire la contention réseau pour les éléments critiques et, dans certains cas, améliorer le LCP. L'audit "Différer les images hors écran" peut vous aider :
Les images critiques au-dessus de la ligne de flottaison, telles que l'image Largest Contentful Paint, ne doivent pas être chargées en différé. Cela peut retarder le chargement de l'image LCP. Lighthouse met en évidence si une image LCP est chargée de manière incorrecte en différé via l'audit "L'image Largest Contentful Paint a été chargée en différé" :
Identifier les contributions au CLS
Le Cumulative Layout Shift mesure la stabilité visuelle. Il quantifie le décalage visuel du contenu d'une page. Lighthouse propose un audit pour déboguer le CLS, intitulé "Éviter les décalages de mise en page importants".
Cet audit met en évidence les éléments DOM qui contribuent le plus aux décalages de la page. Dans la colonne "Élément" à gauche, vous verrez la liste de ces éléments DOM et, à droite, leur contribution globale au CLS.
Grâce à la nouvelle fonctionnalité de capture d'écran des éléments de Lighthouse, nous pouvons voir un aperçu visuel des éléments clés indiqués dans l'audit, et cliquer pour zoomer afin d'obtenir une vue plus claire :
Pour le CLS post-chargement, il peut être utile de visualiser de manière persistante avec des rectangles les éléments qui ont le plus contribué au CLS. Cette fonctionnalité est disponible dans des outils tiers tels que le tableau de bord Core Web Vitals de SpeedCurve. J'aime utiliser le générateur de GIF de décalage de mise en page de Defaced pour :
Pour obtenir une vue d'ensemble des problèmes de décalage de mise en page sur l'ensemble du site, j'utilise beaucoup le rapport Core Web Vitals de la Search Console. Cela me permet de voir les types de pages de mon site qui ont un CLS élevé (dans ce cas, cela m'aide à identifier les parties de modèle sur lesquelles je dois passer du temps) :
Identifier le CLS à partir d'images sans dimensions
Pour limiter le Cumulative Layout Shift causé par des images sans dimensions, incluez des attributs de largeur et de hauteur sur vos images et éléments vidéo. Cette approche garantit que le navigateur peut allouer la bonne quantité d'espace dans le document pendant le chargement de l'image.
Consultez Setting Height And Width On Images Is Important Again (en anglais) pour obtenir un bon article sur l'importance de prendre en compte les dimensions et le format des images.
Identifier le CLS des annonces
Publisher Ads pour Lighthouse vous permet d'identifier les opportunités d'améliorer l'expérience de chargement des annonces sur votre page, y compris les contributions au décalage de mise en page et aux tâches longues qui peuvent retarder le moment où votre page est utilisable par les utilisateurs. Dans Lighthouse, vous pouvez l'activer via les plug-ins de la communauté.
N'oubliez pas que les annonces sont l'un des principaux facteurs de décalage de mise en page sur le Web. Il est important de :
- Faites attention lorsque vous placez des annonces non fixes en haut de la fenêtre d'affichage
- Éliminez les décalages en réservant la plus grande taille possible pour l'espace publicitaire.
Éviter les animations non composées
Les animations non composées peuvent être lentes sur les appareils bas de gamme si des tâches JavaScript lourdes occupent le thread principal. Ces animations peuvent entraîner des décalages de mise en page.
Si Chrome détecte qu'une animation n'a pas pu être compositée, il le signale dans une trace DevTools que Lighthouse lit, ce qui lui permet de lister les éléments avec des animations qui n'ont pas été compositées et pour quelle raison. Vous les trouverez dans l'audit Éviter les animations non composées.
Déboguer le First Input Delay/Total Blocking Time/les tâches longues
Le délai de première interaction mesure le temps écoulé entre le moment où un utilisateur interagit pour la première fois avec une page (par exemple, lorsqu'il clique sur un lien, appuie sur un bouton ou utilise un contrôle personnalisé basé sur JavaScript) et le moment où le navigateur est réellement en mesure de commencer à traiter les gestionnaires d'événements en réponse à cette interaction. Les tâches JavaScript longues peuvent avoir un impact sur cette métrique et sur son proxy, le Total Blocking Time.
Lighthouse inclut un audit Éviter les tâches longues sur le thread principal qui liste les tâches les plus longues sur le thread principal. Cela peut être utile pour identifier les tâches qui entraînent le plus de retard. Dans la colonne de gauche, nous pouvons voir l'URL des scripts responsables des tâches longues du thread principal.
À droite, nous pouvons voir la durée de ces tâches. Pour rappel, les tâches longues sont des tâches qui s'exécutent pendant plus de 50 millisecondes. Cela est considéré comme un blocage du thread principal suffisamment long pour avoir un impact sur la fréquence d'images ou la latence d'entrée.
Si vous envisagez d'utiliser des services tiers pour la surveillance, j'aime aussi beaucoup la chronologie d'exécution du thread principal de Calibre pour visualiser ces coûts, qui met en évidence les tâches parentes et enfants contribuant aux tâches longues qui ont un impact sur l'interactivité.
Bloquez les requêtes réseau pour voir l'impact avant/après dans Lighthouse.
Les outils pour les développeurs Chrome permettent de bloquer les requêtes réseau pour voir l'impact de la suppression ou de l'indisponibilité de ressources individuelles. Cela peut être utile pour comprendre l'impact des scripts individuels (par exemple, les intégrations ou les traceurs tiers) sur des métriques telles que le Total Blocking Time (TBT) et le Time to Interactive.
Le blocage des requêtes réseau fonctionne également avec Lighthouse. Examinons rapidement le rapport Lighthouse d'un site. Le score de performances est de 63/100, avec un TBT de 400 ms. En examinant le code, nous constatons que ce site charge un polyfill Intersection Observer dans Chrome, ce qui n'est pas nécessaire. Bloquons-le !
Nous pouvons effectuer un clic droit sur un script dans le panneau "Réseau" des outils de développement, puis cliquer sur Block Request URL pour le bloquer. Ici, nous allons le faire pour le polyfill Intersection Observer.
Nous pouvons ensuite réexécuter Lighthouse. Cette fois, nous pouvons voir que notre score de performances s'est amélioré (70/100), tout comme le Total Blocking Time (400 ms => 300 ms).
Remplacer les intégrations tierces coûteuses par une façade
Il est courant d'utiliser des ressources tierces pour intégrer des vidéos, des posts sur les réseaux sociaux ou des widgets dans des pages. Par défaut, la plupart des intégrations se chargent immédiatement et peuvent s'accompagner de charges utiles coûteuses qui ont un impact négatif sur l'expérience utilisateur. Cela est inutile si le tiers n'est pas essentiel (par exemple, si l'utilisateur doit faire défiler la page avant de le voir).
Pour améliorer les performances de ces widgets, vous pouvez les charger de manière différée lors de l'interaction de l'utilisateur. Pour ce faire, vous pouvez afficher un aperçu léger du widget (une façade) et ne charger la version complète que si un utilisateur interagit avec lui. Lighthouse propose un audit qui recommande des ressources tierces pouvant être chargées de façon différée avec une façade, comme les intégrations de vidéos YouTube.
Pour rappel, Lighthouse met en évidence le code tiers qui bloque le thread principal pendant plus de 250 ms. Cela peut exposer toutes sortes de scripts tiers (y compris ceux créés par Google) qu'il peut être utile de différer ou de charger de manière différée si ce qu'ils affichent nécessite de faire défiler la page pour l'afficher.
Au-delà des Core Web Vitals
En plus de mettre en avant les métriques Core Web Vitals, les versions récentes de Lighthouse et PageSpeed Insights essaient également de fournir des conseils concrets que vous pouvez suivre pour améliorer la vitesse de chargement des applications Web contenant beaucoup de code JavaScript si vous avez activé les mappages sources.
Il s'agit notamment d'un ensemble croissant d'audits visant à réduire le coût du code JavaScript sur votre page, par exemple en réduisant la dépendance aux polyfills et aux doublons qui ne sont peut-être pas nécessaires pour l'expérience utilisateur.
Pour en savoir plus sur les outils Core Web Vitals, suivez le compte Twitter de l'équipe Lighthouse et consultez Nouveautés des outils de développement.