Comment et pourquoi nous avons créé les insights sur les performances

Jack Franklin

Dans Chrome 102, vous remarquerez un nouveau panneau expérimental, Informations sur les performances, dans vos outils pour les développeurs. Dans cet article, nous allons non seulement expliquer pourquoi nous avons travaillé sur un nouveau panneau, mais aussi aborder les défis techniques auxquels nous avons été confrontés et les décisions que nous avons prises en cours de route.

ALT_TEXT_HERE

Pourquoi créer un autre panneau ?

(Si vous ne l'avez pas encore vue, nous avons publié une vidéo expliquant pourquoi nous avons créé le panneau "Insights sur les performances" et comment vous pouvez obtenir des insights exploitables sur les performances de votre site Web grâce à celui-ci.)

Le panneau "Performances" existant est une excellente ressource si vous souhaitez afficher toutes les données de votre site Web au même endroit, mais nous avons pensé qu'il pouvait être un peu trop complet. Si vous n'êtes pas un expert en performances, il est difficile de savoir exactement ce qu'il faut rechercher et quelles parties de l'enregistrement sont pertinentes.

Le panneau "Insights" vous permet d'afficher la chronologie de votre trace et d'inspecter les données, mais aussi d'obtenir une liste pratique des principaux "insights" que les outils de développement jugent intéressants. Les insights identifieront les problèmes tels que les requêtes bloquant le rendu, les changements de mise en page et les tâches longues, pour n'en citer que quelques-uns. Tous ces problèmes peuvent avoir un impact négatif sur les performances de chargement des pages de votre site Web et, plus précisément, sur les scores Core Web Vitals (CVW) de votre site. En plus de signaler les problèmes, les insights sur les performances vous fourniront des suggestions pratiques pour améliorer vos scores de CVW, ainsi que des liens vers des ressources et de la documentation supplémentaires.

Lien de commentaires dans le panneau

Ce panneau est expérimental. N'hésitez pas à nous faire part de vos commentaires ! N'hésitez pas à nous signaler les bugs que vous rencontrez ou à nous faire part des fonctionnalités qui, selon vous, vous aideront à améliorer les performances de votre site.

Comment nous avons créé les insights sur les performances

Comme le reste des outils de développement, nous avons créé Performance Insights en TypeScript et utilisé des composants Web, soutenus par lit-html, pour créer l'interface utilisateur. La principale différence avec Performance Insights est que l'interface utilisateur principale est un élément HTML canvas, et que la timeline est dessinée sur ce canevas. Une grande partie de la complexité vient de la gestion de ce canevas : non seulement dessiner les bons détails au bon endroit, mais aussi gérer les événements de la souris (par exemple, où l'utilisateur a-t-il cliqué sur le canevas ? Ont-ils cliqué sur un événement que nous avons dessiné ?) et s'assurer que le canevas est redessiné efficacement.

Plusieurs pistes sur un même canevas

Pour un site Web donné, il existe plusieurs "pistes" que nous souhaitons afficher, chacune représentant une catégorie de données différente. Par exemple, le panneau "Insights" affiche trois pistes par défaut :

À mesure que nous ajoutons des fonctionnalités au panneau, nous nous attendons à ce que d'autres titres soient ajoutés.

Notre première idée était que chacune de ces pistes rende son propre <canvas>, de sorte que la vue principale devienne plusieurs éléments canvas empilés verticalement. Cela simplifierait le rendu au niveau de la piste, car chaque piste pourrait être rendue de manière isolée et il n'y aurait aucun risque qu'une piste soit rendue en dehors de ses limites. Malheureusement, cette approche présente deux problèmes majeurs :

Les éléments canvas sont coûteux à (re)rendre. Avoir plusieurs canevas est plus coûteux qu'un seul canevas, même si ce canevas est plus grand. Le rendu des superpositions qui s'étendent sur plusieurs pistes (par exemple, les lignes verticales pour marquer des événements tels que le temps FCP) devient complexe : nous devons effectuer le rendu sur plusieurs canevas et nous assurer qu'ils sont tous rendus ensemble et qu'ils sont correctement alignés.

L'utilisation d'un seul canvas pour l'ensemble de l'UI signifiait que nous devions trouver un moyen de nous assurer que chaque piste s'affiche aux bonnes coordonnées et ne déborde pas sur une autre piste. Par exemple, si une piste particulière mesure 100 px de haut, nous ne pouvons pas autoriser l'affichage d'un élément de 120 px de haut qui empiète sur la piste située en dessous. Pour résoudre ce problème, nous pouvons utiliser clip. Avant d'afficher chaque piste, nous dessinons un rectangle représentant la fenêtre de piste visible. Cela garantit que tous les chemins tracés en dehors de ces limites seront coupés par le canevas.

canvasContext.beginPath();
canvasContext.rect(
    trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();

Nous ne voulions pas non plus que chaque piste connaisse sa position verticale : chaque piste doit se rendre comme si elle se rendait à (0, 0), et nous avons un composant de niveau supérieur (que nous appelons TrackManager) pour gérer la position globale de la piste. Pour ce faire, utilisez translate, qui traduit le canevas par une position (x, y) donnée. Exemple :

canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide

Malgré le paramètre de code rect qui définit 0, 0 comme position, la traduction globale appliquée entraînera l'affichage du rectangle à 0, 10. Cela nous permet de travailler sur une base de piste comme si nous effectuions le rendu à (0, 0), et de demander à notre gestionnaire de pistes de traduire chaque piste lors du rendu pour s'assurer que chaque piste est rendue correctement sous la précédente.

Canevas hors écran pour les pistes et les temps forts

Le rendu du canevas est relativement coûteux. Nous souhaitons nous assurer que le panneau "Insights" reste fluide et réactif lorsque vous l'utilisez. Il est parfois impossible d'éviter de devoir rendre à nouveau l'intégralité du canevas. Par exemple, si vous modifiez le niveau de zoom, nous devons recommencer et tout rendre à nouveau. Le rendu du canevas est particulièrement coûteux, car vous ne pouvez pas simplement en rendre une petite partie. Vous devez effacer l'intégralité du canevas et le redessiner. Contrairement au rendu du DOM, où les outils peuvent calculer le travail minimal requis et ne pas tout supprimer pour recommencer,

Nous avons rencontré des problèmes visuels au niveau de la mise en surbrillance. Lorsque vous pointez sur des métriques dans le volet, nous les mettons en surbrillance dans la chronologie. De même, si vous pointez sur un insight pour un événement donné, nous dessinons une bordure bleue autour de cet événement.

Cette fonctionnalité a d'abord été implémentée en détectant un mouvement de souris sur un élément qui déclenche une mise en surbrillance, puis en dessinant cette mise en surbrillance directement sur le canevas principal. Notre problème survient lorsque nous devons supprimer la mise en surbrillance : la seule option consiste à tout redessiner. Il est impossible de redessiner uniquement la zone où se trouvait la mise en surbrillance (sans apporter d'énormes modifications architecturales). Cependant, redessiner l'intégralité du canevas juste pour supprimer une bordure bleue autour d'un élément semblait excessif. Il y avait également un décalage visuel si vous déplaciez rapidement la souris sur différents éléments pour déclencher plusieurs mises en surbrillance à la suite.

Pour résoudre ce problème, nous avons divisé notre UI en deux canevas hors écran : le canevas "principal", où les pistes sont rendues, et le canevas "temps forts", où les temps forts sont dessinés. Nous effectuons ensuite le rendu en copiant ces canevas sur le canevas unique visible à l'écran par l'utilisateur. Nous pouvons utiliser la méthode drawImage sur un contexte de canevas, qui peut prendre un autre canevas comme source.

Cela signifie que la suppression d'une mise en surbrillance n'entraîne pas le redessin du canevas principal. Au lieu de cela, nous pouvons effacer le canevas à l'écran, puis copier le canevas principal sur le canevas visible. La copie d'un canevas est peu coûteuse, contrairement au dessin. En déplaçant les surlignages sur un canevas distinct, nous évitons ce coût lorsque nous activons et désactivons les surlignages.

Analyse des traces entièrement testée

L'un des avantages de créer une fonctionnalité à partir de zéro est que vous pouvez réfléchir aux choix techniques effectués précédemment et les améliorer. L'un des aspects que nous souhaitions améliorer était de diviser explicitement notre code en deux parties presque entièrement distinctes :

Analysez le fichier de trace et extrayez les données requises. Afficher un ensemble de pistes.

En séparant l'analyse (partie 1) du travail sur l'UI (partie 2), nous avons pu créer un système d'analyse solide. Chaque trace est exécutée par une série de gestionnaires qui sont responsables de différents aspects : un LayoutShiftHandler calcule toutes les informations dont nous avons besoin pour les changements de mise en page et un NetworkRequestsHandler s'occupe exclusivement d'extraire les requêtes réseau. Cette étape d'analyse explicite, où différents gestionnaires sont responsables de différentes parties de la trace, s'est également avérée utile. L'analyse des traces peut devenir très complexe, et il est utile de pouvoir se concentrer sur un problème à la fois.

Nous avons également pu tester de manière exhaustive l'analyse des traces en enregistrant des données dans les outils de développement, en les enregistrant, puis en les chargeant dans notre suite de tests. C'est un avantage, car nous pouvons effectuer des tests avec de vraies traces, sans avoir à générer d'énormes quantités de données de trace factices qui pourraient devenir obsolètes.

Tests de capture d'écran pour l'UI Canvas

En parlant de tests, nous testons généralement nos composants frontend en les affichant dans le navigateur et en nous assurant qu'ils se comportent comme prévu. Nous pouvons envoyer des événements de clic pour déclencher des mises à jour et nous assurer que le DOM généré par les composants est correct. Cette approche fonctionne bien pour nous, mais elle ne convient pas pour le rendu sur un canevas. En effet, il n'existe aucun moyen d'inspecter un canevas et de déterminer ce qui y est dessiné. Notre approche habituelle, qui consiste à afficher le contenu, puis à interroger la base de données, n'est donc pas appropriée.

Pour obtenir une couverture de test, nous avons opté pour les tests de capture d'écran. Chaque test lance un canevas, affiche la piste que nous voulons tester, puis prend une capture d'écran de l'élément de canevas. Cette capture d'écran est ensuite stockée dans notre base de code. Les futurs tests compareront la capture d'écran stockée à celle qu'ils généreront. Si les captures d'écran sont différentes, le test échouera. Nous fournissons également un indicateur permettant d'exécuter le test et de forcer la mise à jour d'une capture d'écran lorsque nous avons volontairement modifié le rendu et que le test doit être mis à jour.

Les tests de capture d'écran ne sont pas parfaits et sont un peu bruts. Vous ne pouvez tester que le rendu de l'ensemble du composant, plutôt que des assertions plus spécifiques. Au début, nous avions tendance à les utiliser à l'excès pour nous assurer que chaque composant (HTML ou canvas) s'affichait correctement. Cela a considérablement ralenti notre suite de tests et a entraîné des problèmes où de petits ajustements de l'interface utilisateur, presque insignifiants (comme de subtils changements de couleur ou l'ajout d'une marge entre les éléments), ont entraîné l'échec de plusieurs captures d'écran et ont nécessité leur mise à jour. Nous avons réduit notre utilisation des captures d'écran, que nous réservons désormais aux composants basés sur le canevas. Cet équilibre nous a bien servi jusqu'à présent.

Conclusion

L'équipe a beaucoup apprécié et appris en créant le nouveau panneau "Informations sur les performances". Nous avons beaucoup appris sur les fichiers de trace, l'utilisation du canevas et bien plus encore. Nous espérons que vous apprécierez ce nouveau panneau et nous avons hâte de connaître votre avis.

Pour en savoir plus sur le panneau "Informations sur les performances", consultez Informations sur les performances : obtenez des insights exploitables sur les performances de votre site Web.

Télécharger les canaux de prévisualisation

Envisagez d'utiliser Chrome Canary, Dev ou Beta comme navigateur de développement par défaut. Ces canaux d'aperçu vous donnent accès aux dernières fonctionnalités des outils de développement, vous permettent de tester les API de plate-forme Web de pointe et vous aident à identifier les problèmes sur votre site avant vos utilisateurs.

Contacter l'équipe des Outils pour les développeurs Chrome

Utilisez les options suivantes pour discuter des nouvelles fonctionnalités, des mises à jour ou de tout autre élément lié aux outils pour les développeurs.