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 ce post, nous allons vous expliquer non seulement pourquoi nous travaillons sur un nouveau panel, mais aussi les défis techniques auxquels nous avons été confrontés et les décisions que nous avons prises au cours de cette procédure.

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 créer le panneau "Insights sur les performances" et comment en tirer des insights pratiques sur les performances de votre site Web.)

Le panneau "Performances" existant est une excellente ressource si vous souhaitez consulter toutes les données de votre site Web en un seul endroit. Toutefois, nous avons estimé qu'il pouvait être un peu intimidant. 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.

Accédez au panneau "Insights", où vous pouvez toujours afficher une chronologie de votre trace et inspecter les données, mais aussi obtenir une liste pratique de ce que DevTools considère comme les principaux "insights" à examiner. Les insights identifient des problèmes tels que les requêtes bloquant le rendu, les décalages de mise en page et les tâches longues, qui peuvent tous avoir un impact négatif sur les performances de chargement des pages de votre site Web, en particulier sur ses scores Core Web Vitals (CWV). En plus de signaler des problèmes, les insights sur les performances vous fournissent des suggestions concrètes pour améliorer vos scores "Signaux Web essentiels" et fournissent des liens vers d'autres ressources et documents.

Lien de commentaires dans le panneau

Ce panneau est expérimental et nous aimerions connaître votre avis. N'hésitez pas à nous contacter si vous rencontrez des bugs ou si vous avez des demandes de fonctionnalités qui, selon vous, pourraient vous aider à améliorer les performances de votre site.

Comment nous avons créé les insights sur les performances

Comme pour le reste de DevTools, nous avons créé Performance Insights en TypeScript et utilisé des composants Web, compatibles avec lit-html, pour créer l'interface utilisateur. L'interface principale de Performance Insights est un élément HTML canvas et la chronologie est tracée sur ce canevas. La complexité vient principalement de la gestion de ce canevas : il ne s'agit pas seulement de dessiner les bons détails au bon endroit, mais aussi de gérer les événements de la souris (par exemple, où l'utilisateur a-t-il cliqué sur le canevas ? A-t-il cliqué sur un événement que nous avons dessiné ?) et nous nous assurons de bien recréer le canevas.

Plusieurs pistes sur un seul canevas

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

À mesure que nous ajouterons des fonctionnalités au panneau, nous prévoyons d'ajouter d'autres canaux.

Notre idée initiale était que chacun de ces canaux génère son propre <canvas>, de sorte que la vue principale devienne plusieurs éléments de canevas empilés verticalement. Cela simplifierait le rendu au niveau des canaux, car chaque canal pourrait être rendu de manière isolée et il n'y aurait aucun risque de rendu d'un canal en dehors de ses limites. Malheureusement, cette approche présente deux problèmes majeurs:

L'affichage (et le re-rendu) des éléments canvas est coûteux. Avoir plusieurs canevas est plus coûteux qu'un seul canevas, même s'il est plus grand. L'affichage de superpositions qui s'étendent sur plusieurs pistes (par exemple, des lignes verticales pour marquer des événements tels que le temps de FCP) devient complexe: nous devons afficher sur plusieurs canevas et nous assurer qu'ils sont tous affichés ensemble et alignés correctement.

L'utilisation d'un seul canvas pour l'ensemble de l'interface utilisateur nous a obligés à trouver un moyen de nous assurer que chaque piste s'affiche aux bonnes coordonnées et ne déborde pas sur une autre. Par exemple, si un canal particulier mesure 100 pixels de haut, nous ne pouvons pas lui permettre d'afficher un élément de 120 pixels de haut et de le faire déborder sur le canal situé 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. Ainsi, tous les chemins tracés en dehors de ces limites seront tronqué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 verticalement: chaque piste devrait s'afficher comme si elle s'affichait à la position (0, 0) et nous disposons d'un composant de niveau supérieur (appelé TrackManager) pour gérer la position globale du titre. Pour ce faire, utilisez translate, qui traduit le canevas en fonction d'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

Bien que le code rect définisse 0, 0 comme position, la translation globale appliquée entraînera l'affichage du rectangle à 0, 10. Cela nous permet de travailler par piste comme si nous effectuions le rendu à (0, 0) et de demander à notre gestionnaire de pistes de traduire chaque piste au fur et à mesure de son rendu pour nous assurer qu'elle est correctement affichée sous la précédente.

Canevas hors écran pour les pistes et les repères

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 recalculer l'intégralité du canevas: par exemple, si vous modifiez le niveau de zoom, nous devons recommencer et tout recalculer. Le rendu du canevas est particulièrement coûteux, car vous ne pouvez pas simplement recréer une petite partie de celui-ci. Vous devez effacer l'intégralité du canevas et le redessiner. Contrairement au re-rendu du DOM, les outils peuvent calculer le travail minimal requis et ne pas tout supprimer et recommencer.

L'un des domaines où nous avons rencontré des problèmes visuels était la mise en évidence. Lorsque vous pointez sur des métriques dans le volet, elles sont mises en surbrillance sur la chronologie. De même, si vous pointez sur un insight pour un événement donné, une bordure bleue apparaît autour de cet événement.

Cette fonctionnalité a d'abord été implémentée en détectant un mouvement de la souris sur un élément qui déclenche un surlignage, puis en dessinant ce surlignage directement sur le canevas principal. Le problème se pose lorsque nous devons supprimer la mise en surbrillance: la seule option est de tout redessiner. Il est impossible de redessiner simplement la zone où se trouvait la mise en surbrillance (sans d'énormes changements d'architecture), mais redessiner l'intégralité du canevas juste pour supprimer une bordure bleue autour d'un élément nous semblait excessif. Il y avait également un décalage visuel si vous pointiez rapidement votre souris sur différents éléments pour déclencher plusieurs surlignages de suite.

Pour résoudre ce problème, nous avons divisé notre UI en deux canevas hors écran: le canevas "principal", sur lequel les pistes sont affichées, et le canevas "points forts", sur lequel les points 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 utiliser un autre canevas comme source.

Cela signifie que la suppression d'un surlignage ne provoque pas le redessin du canevas principal. Nous pouvons plutôt effacer le canevas à l'écran, puis copier le canevas principal sur le canevas visible. La copie d'un canevas est peu coûteuse, c'est le dessin qui l'est. En déplaçant les rehauts sur un canevas distinct, nous évitons ce coût lorsque nous activons et désactivons les rehauts.

Analyse des traces testée de manière exhaustive

L'un des avantages de créer une nouvelle fonctionnalité en partant de zéro est que vous pouvez réfléchir aux choix techniques faits précédemment et apporter des améliorations. L'une des choses que nous voulions améliorer était de diviser explicitement notre code en deux parties presque entièrement distinctes:

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

Le fait de séparer l'analyse (partie 1) du travail de l'interface utilisateur (partie 2) nous a permis de créer un système d'analyse fiable. Chaque trace est exécutée par une série de gestionnaires responsables de différents aspects: un LayoutShiftHandler calcule toutes les informations dont nous avons besoin pour les décalages de mise en page et un NetworkRequestsHandler s'occupe exclusivement d'extraire les requêtes réseau. Cette étape d'analyse explicite, au cours de laquelle différents gestionnaires sont responsables de différentes parties de la trace, s'est également révélée bénéfique: l'analyse des traces peut devenir très compliquée et permet de se concentrer sur un problème à la fois.

Nous avons également pu tester de manière exhaustive l'analyse des traces en effectuant des enregistrements dans DevTools, en les enregistrant, puis en les chargeant dans notre suite de tests. C'est une excellente chose, car nous pouvons effectuer des tests avec des traces réelles et ne pas accumuler d'énormes quantités de données de trace factices qui pourraient devenir obsolètes.

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

Pour rester dans le domaine des tests, nous testons généralement nos composants frontend en les affichant dans le navigateur et en nous assurant qu'ils fonctionnent 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 ne fonctionne pas lorsque vous envisagez d'effectuer un rendu sur un canevas. Il n'y a aucun moyen d'inspecter un canevas et de déterminer ce qui y est dessiné. Par conséquent, notre approche habituelle consistant à effectuer un rendu, puis à effectuer des requêtes n'est pas appropriée.

Pour obtenir une couverture de test, nous avons eu recours aux tests de captures d'écran. Chaque test lance un canevas, affiche le canal que nous souhaitons tester, puis prend une capture d'écran de l'élément de canevas. Cette capture d'écran est ensuite stockée dans notre codebase, et les tests ultérieurs compareront la capture d'écran stockée à la capture d'écran générée. 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 de la capture d'écran lorsque nous avons délibérément modifié le rendu et que le test doit être mis à jour.

Les tests de captures d'écran ne sont pas parfaits et sont un peu net. Vous ne pouvez que vérifier que l'intégralité du composant s'affiche comme prévu, plutôt que des assertions plus spécifiques. Au départ, nous étions responsables de leur utilisation excessive pour nous assurer que chaque composant (HTML ou canevas) s'affichait correctement. Cela a ralenti notre suite de tests de manière drastique et a entraîné des problèmes où de minuscules modifications d'UI presque insignifiantes (telles que 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 et les utilisons uniquement pour les composants basés sur le canevas. Cet équilibre nous a bien servi jusqu'à présent.

Conclusion

La création du nouveau panneau "Informations sur les performances" a été une expérience très agréable et instructive pour l'équipe. Nous avons beaucoup appris sur les fichiers de suivi, le 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 Bêta comme navigateur de développement par défaut. Ces canaux de prévisualisation vous donnent accès aux dernières fonctionnalités de DevTools, vous permettent de tester les API de plates-formes Web de pointe et vous aident à détecter 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.