00:00:00GitHub vient de sortir un module complémentaire très puissant pour Storybook qui change
00:00:05radicalement la façon dont nous testons la performance des composants.
00:00:07Il inclut un panneau de performance très détaillé rempli d'analyses précieuses comme la mesure
00:00:12du timing des images, la réactivité, la stabilité de la mise en page, le profilage React,
00:00:18la pression mémoire et bien plus encore.
00:00:19Dans cette vidéo, nous allons examiner de plus près ce que cet add-on a à offrir.
00:00:23Ça va être très intéressant, alors plongeons dans le vif du sujet.
00:00:31Petite question avant de commencer.
00:00:32Savez-vous ce qu'est le test de performance “shift-left” ?
00:00:35C'est un paradigme de développement qui dicte que la performance de vos composants
00:00:40doit être testée plus tôt dans le processus, plutôt qu'après coup.
00:00:45Cet outil est spécifiquement conçu pour aider les développeurs à prendre ces décisions précoces,
00:00:50en vous donnant un aperçu en temps réel du comportement de vos composants avant la production.
00:00:55Le panneau de performance de Storybook offre ainsi un regard de haute fidélité sur
00:01:00l'interaction de vos composants avec le moteur de rendu du navigateur.
00:01:02Il suit, par exemple, le timing des images pour identifier le “jitter”, ces minuscules
00:01:07écarts irréguliers entre les images qui rendent les animations saccadées.
00:01:10Il surveille également le thread principal pour détecter le brassage et l'agitation du DOM.
00:01:15Le brassage du DOM se produit lorsque votre code crée, supprime ou met à jour inutilement
00:01:20des éléments en boucle, tandis que l'agitation survient quand le navigateur doit
00:01:25recalculer la mise en page plusieurs fois par image car vous modifiez les styles en rafale.
00:01:30Et cet add-on s'adapte à n'importe quel framework que vous utilisez.
00:01:33Si vous utilisez React, il peut mettre en évidence des métriques comme les cascades de rendu,
00:01:38ces petits changements d'état qui déclenchent accidentellement une vague de re-rendus lents.
00:01:44Il suit également la durée P95, qui montre le pire scénario pour vos utilisateurs
00:01:50les plus lents plutôt qu'une simple moyenne.
00:01:52Et si vous n'utilisez pas React, le mode universel fonctionne parfaitement pour
00:01:58Vue, Svelte ou les composants web.
00:01:59Pour de meilleurs résultats, il est recommandé d'utiliser cet add-on sur Chrome ou Edge.
00:02:04Ils ont aussi un manuel interactif où l'on peut voir ces métriques en action.
00:02:08Par exemple, dans l'exemple de la boîte animée, nous pouvons suivre exactement
00:02:13combien de mutations de style en ligne se produisent pendant l'animation.
00:02:16Dans ce cas précis, tout semble sain.
00:02:18Le taux et le temps de rafraîchissement restent parfaitement stables, ce qui signifie
00:02:23que le navigateur gère ces mises à jour de style sans aucun effort.
00:02:25Cependant, l'exemple de la liste lourde raconte une tout autre histoire.
00:02:29Lorsque nous filtrons cette longue liste, nous voyons quelques signaux d'alerte.
00:02:32D'abord, le décalage de mise en page cumulatif grimpe à une valeur très élevée,
00:02:38indiquant que les éléments sautent de façon importante, créant une expérience désagréable.
00:02:43On voit aussi un pic de brassage du DOM, signifiant que le navigateur travaille trop
00:02:49pour supprimer et reconstruire un nombre massif de nœuds d'un seul coup.
00:02:52Cela entraîne également des pertes d'images, ce qui nuit à la vitesse perçue
00:02:57et à la fluidité de l'interface.
00:02:58Dans l'exemple de timing d'élément, tout élément DOM avec cet attribut est mesuré
00:03:04pour son temps de rendu exact.
00:03:06C'est incroyablement utile car cela vous aide à identifier le moment précis où
00:03:11votre contenu principal ou votre appel à l'action devient visible, offrant une image
00:03:17plus précise de la performance perçue que les métriques de chargement génériques.
00:03:21Et dans l'exemple du rendu coûteux, si nous cliquons sur le bouton de re-rendu,
00:03:26cela fait grimper la durée P95 en flèche.
00:03:29Cela arrive car le thread principal est pris en otage par l'exécution lourde de JavaScript,
00:03:34rendant l'interface utilisateur très poussive.
00:03:36Nous voyons aussi des alertes de saccades d'images, indiquant un rendu incohérent
00:03:41où le temps entre les images fluctue énormément.
00:03:44Il y a aussi un temps de blocage total (TBT) élevé.
00:03:47Le TBT est un avertissement majeur car il indique que le thread principal a été bloqué
00:03:52assez longtemps pour empêcher l'utilisateur d'interagir avec la page,
00:03:57comme cliquer sur un bouton ou faire défiler.
00:03:58Nous voyons une analyse similaire dans l'exemple de gaspillage de mémoïsation.
00:04:03Ici, la démo montre que le re-rendu inutile de chaque élément entraîne un retard massif.
00:04:08En revanche, l'exemple correctement mémoïsé montre tout le travail économisé
00:04:09si nous mémoïsons nos composants.
00:04:15En sautant ces rendus redondants, nous libérons le thread principal et maintenons
00:04:16le taux d'images stable pour obtenir une fluidité parfaite à 60 images par seconde.
00:04:21Dans l'exemple de cascade de rendu, nous voyons exactement ce qui se passe
00:04:25quand on utilise “set state” à l'intérieur de “use layout effect”.
00:04:30Chaque incrément déclenche une cascade car “use layout effect” s'exécute de façon synchrone
00:04:31après les mutations du DOM, mais avant que le navigateur n'ait pu dessiner.
00:04:37En déclenchant la mise à jour de l'état ici, vous forcez React à retraiter l'arborescence
00:04:42et le navigateur à recalculer la mise en page une seconde fois avant même que
00:04:47l'utilisateur ne voie le premier résultat.
00:04:52C'est problématique car cela double effectivement le travail pour chaque image,
00:04:53créant un retard de rendu qui alourdit même les interactions simples.
00:04:58Il y a ensuite l'exemple d'agitation de style qui démontre une observation critique.
00:05:02Que se passe-t-il si nous modifions les styles en ligne de 600 nœuds différents à la fois ?
00:05:07Nous voyons immédiatement ces avertissements de blocage dans la section agitation,
00:05:13indiquant que le navigateur est forcé dans une boucle de redistribution.
00:05:18Il essaie de calculer les positions de 600 éléments simultanément alors que
00:05:21le JavaScript est encore en train d'effectuer des modifications.
00:05:26Cela conduit à des mesures d'images très mauvaises car le thread principal est
00:05:27complètement saturé.
00:05:33J'espère que ces exemples vous montrent comment utiliser cet add-on Storybook
00:05:34pour identifier les goulots d'étranglement dans un environnement bien plus précis.
00:05:38Bien sûr, on peut utiliser Lighthouse, mais c'est un outil très global.
00:05:41Il ne donne pas cette précision chirurgicale pour voir exactement comment
00:05:46un composant individuel impacte la performance de votre application.
00:05:51Je vous encourage vivement à télécharger cet add-on et à l'ajouter à votre suite Storybook.
00:05:53Il y a tant d'enseignements précieux à tirer une fois que vous voyez l'image complète
00:05:58du fonctionnement réel de vos composants sous le capot.
00:05:59Voilà donc, en résumé, le nouveau panneau de performance Storybook de GitHub.
00:06:03Qu'en pensez-vous ?
00:06:06Et comment mesurez-vous la performance dans votre application ?
00:06:10Dites-le nous dans les commentaires ci-dessous.
00:06:11Si vous aimez ce genre d'analyses techniques, faites-le moi savoir en cliquant
00:06:13sur le bouton “j'aime” sous la vidéo et n'oubliez pas de vous abonner.
00:06:16C'était Andres de Better Stack, on se retrouve dans les prochaines vidéos.