Dans Chrome 102, vous remarquerez un nouveau panneau expérimental, Performance Insights, dans les outils de développement. Dans ce post, nous expliquons non seulement pourquoi nous avons travaillé sur un nouveau panel, mais aussi les défis techniques que nous avons rencontrés et les décisions que nous avons prises au cours de ce processus.
Pourquoi créer un autre panneau ?
Si vous ne l'avez pas déjà fait, nous avons publié une vidéo expliquant pourquoi il est important de créer le panneau "Insights sur les performances" et comment il peut vous aider à obtenir des insights exploitables sur les performances de votre site Web.
Le panneau "Performances existant" est une excellente ressource si vous voulez consulter toutes les données de votre site Web au même endroit. Cependant, nous avons trouvé que cela pouvait vous contrarier. 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". Vous pourrez toujours consulter la chronologie de votre trace et inspecter les données, mais aussi obtenir une liste pratique des principaux insights que les outils de développement considèrent comme les principaux "insights". Les insights identifient des problèmes tels que les demandes qui bloquent l'affichage, les décalages de mise en page et les longues tâches, pour n'en citer que quelques-uns. Ils peuvent tous avoir un impact négatif sur les performances de chargement des pages de votre site Web, et plus particulièrement sur les scores Core Web Vitals de votre site. En plus du signalement des problèmes, les insights sur les performances vous fournissent des suggestions exploitables pour améliorer vos scores CWV, et fournissent des liens vers d'autres ressources et documentations.
Ce panneau est au stade expérimental, et votre avis nous intéresse ! N'hésitez pas à nous contacter si vous rencontrez des bugs ou si vous souhaitez demander des fonctionnalités qui pourraient vous aider à améliorer les performances de votre site.
Comment nous avons créé les insights sur les performances
Comme pour le reste des outils de développement, nous avons développé les insights sur les performances dans TypeScript et utilisé des composants Web, reposant sur lit-html, pour créer l'interface utilisateur. Les différences entre Performance Insights et le fait que l'interface utilisateur principale est un élément HTML canvas, avec la chronologie dessinée sur ce canevas. La gestion de ce canevas est en grande partie complexe : vous pouvez non seulement dessiner les bons détails au bon endroit, mais aussi gérer les événements de 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 s'est-il assuré que le canevas s'affiche à nouveau correctement.
Plusieurs pistes sur une même toile
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" affichera trois canaux par défaut:
Et à mesure que nous ajouterons des éléments au panel, nous nous attendons à ce que davantage de canaux soient ajoutés.
Au départ, nous voulions que chacune de ces pistes affiche sa propre <canvas>, de sorte que la vue principale se transforme en plusieurs éléments de canevas empilés verticalement. Cela simplifierait le rendu au niveau des pistes, car chaque piste pourrait être rendue de manière isolée et il n'y aurait aucun risque que la piste soit rendue en dehors de ses limites. Malheureusement, cette approche présente deux problèmes majeurs:
Le (ré)affichage des éléments canvas coûte cher. Disposer de plusieurs canevas coûte plus cher qu'un seul canevas, même s'il est plus grand.
L'affichage de toute superposition sur plusieurs pistes (par exemple, des lignes verticales pour marquer des événements tels que l'heure FCP) devient complexe: nous devons effectuer le rendu sur plusieurs canevas, et nous assurer qu'ils sont tous affichés ensemble et qu'ils s'alignent correctement.
L'utilisation d'un canvas pour l'ensemble de l'UI nous a permis de s'assurer que chaque piste s'affiche aux bonnes coordonnées et ne déborde pas sur une autre piste. Par exemple, si une piste fait 100 pixels de haut, nous ne pouvons pas l'autoriser à afficher un élément de 120 pixels de haut et qu'elle soit à fond perdu dans la piste située en dessous. Pour résoudre ce problème, nous pouvons utiliser clip. Avant d'effectuer le rendu de chaque piste, nous dessinons un rectangle représentant la fenêtre de la piste visible. Cela permet de s'assurer que tous les tracés tracés en dehors de ces limites seront rogné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 s'afficher comme si elle s'affichait à (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 selon 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îne l'affichage du rectangle à 0, 10. Cela nous permet de travailler sur les pistes comme si nous avions atteint (0, 0) et de faire en sorte que notre gestionnaire de suivi effectue le rendu de chaque piste afin de s'assurer que chaque piste s'affiche correctement en dessous de la précédente.
Toiles hors écran pour les titres et les temps forts
Le rendu du canevas est relativement cher, et nous voulons nous assurer que le panneau "Insights" reste fluide et réactif lorsque vous l'utilisez. Il est parfois impossible d'éviter de devoir réafficher l'intégralité du canevas. Par exemple, si vous modifiez le niveau de zoom, nous devons recommencer le rendu et effectuer un nouveau rendu. Le réaffichage du canevas est particulièrement coûteux, car il ne suffit pas d'en afficher une petite partie. Vous devez effacer l'intégralité du canevas et le redessiner. Cela diffère du réaffichage DOM, qui permet aux outils de calculer le travail minimal requis et de ne pas tout supprimer pour recommencer.
Nous avons rencontré des problèmes visuels concernant la mise en évidence. Lorsque vous pointez sur les statistiques du volet, elles sont mises en évidence dans 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 souris sur un élément qui déclenche une mise en surbrillance, puis en dessinant cette mise en surbrillance directement sur le canevas principal. Ce problème survient lorsque nous devons supprimer la mise en surbrillance: la seule option est de tout redessiner. Il est impossible de se contenter de redessiner la zone à l'endroit où se trouvait la mise en surbrillance (ce qui n'a pas échappé à d'importants changements architecturals), mais de redessiner l'intégralité du canevas simplement pour supprimer une bordure bleue autour d'un élément semblait exagéré. L'affichage était également décalé si vous déplacez rapidement le curseur de la souris sur différents éléments pour déclencher plusieurs sélections à la suite.
Pour résoudre ce problème, nous avons divisé l'interface utilisateur en deux canaux hors écran: le canevas "principal", où les pistes sont affichées, et le canevas "highlights", où les éléments en surbrillance sont dessinés. Nous effectuons ensuite le rendu en copiant ces canevas sur un canevas unique que l'utilisateur peut voir à l'écran. 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'une mise en surbrillance n'entraîne pas le redessin du canevas principal. À la place, nous pouvons effacer le canevas à l'écran, puis copier le canevas principal sur le canevas visible. Copier un canevas n'est pas cher, c'est le dessin qui coûte cher. Par conséquent, en déplaçant les tons clairs sur un canevas distinct, nous évitons ce coût lors de l'activation et de la désactivation des tons clairs.
Analyse de trace entièrement testée
En créant une nouvelle fonctionnalité de A à Z, vous avez l'avantage de pouvoir réfléchir aux choix techniques faits précédemment et d'apporter des améliorations. L'une des choses que nous voulions améliorer consistait à diviser explicitement notre code en deux parties, presque entièrement distinctes:
Analyser le fichier de suivi et extraire les données requises. Affichez un ensemble de pistes.
La séparation de 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 qui sont responsables de différents problèmes: un LayoutShiftHandler calcule toutes les informations dont nous avons besoin pour les décalages de mise en page et un NetworkRequestsHandler s'occupe exclusivement de l'extraction des requêtes réseau. Cette étape d'analyse explicite impliquant plusieurs gestionnaires responsables de différentes parties de la trace a également été bénéfique: l'analyse des traces peut devenir très compliquée, et cela permet de se concentrer sur une préoccupation à la fois.
Nous avons également pu tester de manière exhaustive notre analyse des traces en enregistrant des enregistrements dans les outils de développement, en les enregistrant, puis en les chargeant dans notre suite de tests. C'est une bonne chose, car nous pouvons effectuer des tests avec des traces réelles, sans accumuler d'énormes quantités de données de trace factices qui pourraient devenir obsolètes.
Test de capture d'écran pour l'interface utilisateur de canevas
Dans la continuité des tests, nous testons généralement nos composants de l'interface 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 vérifier que le DOM généré par les composants est correct. Cette approche fonctionne bien pour nous, mais elle échoue lors du rendu sur un canevas. Il n'y a aucun moyen d'inspecter un canevas et de déterminer ce qui y est dessiné. Notre approche habituelle d'affichage et d'interrogation n'est donc pas appropriée.
Pour pouvoir tester la couverture, nous nous sommes tournés vers les tests de captures d'écran. Chaque test déclenche un canevas, affiche la piste à 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 futurs tests 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 pour exécuter le test et forcer la mise à jour des captures 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 brusques. Vous ne pouvez vérifier que l'intégralité du composant s'affiche comme prévu, et non à l'aide d'assertions plus spécifiques. Au départ, nous étions coupables de les utiliser de manière excessive pour vérifier que chaque composant (HTML ou canevas) s'affiche correctement. Cela ralentit considérablement notre suite de tests et entraîne des problèmes où de minuscules ajustements presque non pertinents de l'interface utilisateur (changements de couleur subtils ou ajout d'une marge entre les éléments, par exemple) provoquaient l'échec de plusieurs captures d'écran et nécessitaient une mise à jour. Nous avons réduit notre utilisation des captures d'écran et nous les utilisons uniquement pour des composants basés sur des canevas. Cet équilibre a déjà bien fonctionné pour nous jusqu'à présent.
Conclusion
La création du nouveau panneau "Insights sur les performances" a été une expérience enrichissante et éducative pour l'équipe. Nous avons appris de nombreuses choses sur les fichiers de suivi, l'utilisation des canevas et bien plus encore. Nous espérons que vous apprécierez le nouveau panel et nous avons hâte de lire vos commentaires.
Pour en savoir plus sur le panneau "Insights sur les performances", consultez l'article Insights sur les performances: obtenez des insights exploitables sur les performances de votre site Web.
Télécharger les canaux de prévisualisation
Nous vous conseillons d'utiliser Chrome Canary, Dev ou Beta comme navigateur de développement par défaut. Ces versions preview vous permettent d'accéder aux dernières fonctionnalités des outils de développement, de tester des API de pointe de plates-formes Web et de détecter les problèmes sur votre site avant qu'ils ne le fassent.
Contacter l'équipe des outils pour les développeurs Chrome
Utilisez les options suivantes pour discuter des nouvelles fonctionnalités et des modifications dans l'article, ou de toute autre question concernant les outils de développement.
- Envoyez-nous une suggestion ou des commentaires via crbug.com.
- Signalez un problème dans les outils de développement via Plus d'options
> Aide > Signaler un problème dans les outils de développement dans les Outils de développement. - Envoyez un tweet à @ChromeDevTools.
- Dites-nous en plus sur les nouveautés concernant les vidéos YouTube dans les outils de développement ou sur les vidéos YouTube de nos conseils relatifs aux outils de développement.