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 expliquer pourquoi nous avons travaillé sur un nouveau panneau, mais aussi les défis techniques auxquels nous avons été confrontés et les décisions que nous avons prises en cours de route.
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 les problèmes, les insights sur les performances vous fourniront des suggestions pratiques pour améliorer vos scores CWV, ainsi que des liens vers d'autres ressources et documentations.
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. La principale différence entre Performance Insights et les autres outils est que l'interface utilisateur principale est un élément HTML canvas
, et que la chronologie est dessiné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 même canevas
Pour un site Web donné, nous souhaitons afficher plusieurs "pistes", chacune 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. Cela garantit que tous les tracés dessiné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 ait à connaître sa position verticale: chaque piste doit s'afficher comme si elle était affichée à (0, 0), et nous disposons d'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 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
L'affichage du canevas est relativement coûteux. Nous souhaitons nous assurer que le panneau "Insights" reste fluide et réactif lorsque vous l'utilisez. Parfois, vous ne pouvez pas é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.
Nous avons rencontré des problèmes visuels au niveau de la mise en surbrillance. Lorsque vous pointez sur une métrique dans le volet, nous la mettons en surbrillance sur la chronologie. De même, si vous pointez sur une 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 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 repères sur un canevas distinct, nous évitons ce coût lorsque nous les activons et les désactivons.
Analyse des traces testée de manière exhaustive
L'un des avantages de créer une nouvelle 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'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 trace et extrayez les données requises. Afficher un ensemble de pistes.
En séparant l'analyse (partie 1) du travail d'UI (partie 2), nous avons pu créer un système d'analyse solide. Chaque trace est exécutée via une série de gestionnaires chargés 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 de récupérer les requêtes réseau. L'étape d'analyse explicite, dans laquelle différents gestionnaires sont responsables de différentes parties de la trace, a également été bénéfique: l'analyse de la trace peut être très complexe, et cette étape permet de se concentrer sur un problème à la fois.
Nous avons également pu tester de manière exhaustive notre 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 en revenir aux tests, nous testons généralement nos composants frontaux en les affichant dans le navigateur et en nous assurant qu'ils se comportent comme prévu. Nous pouvons distribuer 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 échoue lorsque nous envisageons de l'utiliser pour le rendu sur un canevas. Il n'existe 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 la piste 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 futures exécutions de test compareront la capture d'écran stockée à celle qu'elles génèrent. 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 d'une capture d'écran lorsque nous avons modifié intentionnellement le rendu et que le test doit être mis à jour.
Les tests de capture d'écran ne sont pas parfaits et sont un peu brutaux. Vous ne pouvez tester que le rendu de l'ensemble du composant, plutôt que des assertions plus spécifiques. Au départ, nous les avons utilisés de manière excessive pour nous assurer que chaque composant (HTML ou canevas) s'affiche 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 appris beaucoup de choses 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 "Performances Insights", consultez Performances Insights: 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 plate-forme 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.
- Envoyez-nous vos commentaires et vos demandes de fonctionnalités sur crbug.com.
- Signalez un problème dans les outils de développement à l'aide de l'icône Plus d'options > Aide > Signaler un problème dans les outils de développement dans les outils de développement.
- Envoyez un tweet à @ChromeDevTools.
- Laissez des commentaires sur les vidéos YouTube sur les nouveautés des outils pour les développeurs ou sur les vidéos YouTube sur les conseils concernant les outils pour les développeurs.