Boostez vos composants React en un clin d'œil ! (Nouvel addon GitHub Storybook)

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

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.

Key Takeaway

Le nouvel add-on de performance de GitHub pour Storybook révolutionne le développement front-end en permettant aux développeurs d'identifier et de corriger les goulots d'étranglement au niveau des composants individuels avant la mise en production.

Highlights

L'introduction du nouveau module de performance de GitHub pour Storybook permet une analyse chirurgicale des composants.

Le concept de test "shift-left" encourage les développeurs à évaluer la performance dès les premières phases du développement.

L'outil mesure des métriques précises comme le jitter des images, le brassage du DOM et l'agitation (layout thrashing).

Une distinction claire est faite entre le mode spécifique à React et le mode universel pour Vue, Svelte ou les composants Web.

L'analyse de la durée P95 et du Temps de Blocage Total (TBT) aide à identifier les pires scénarios d'expérience utilisateur.

La démonstration prouve l'importance de la mémoïsation pour maintenir un taux de rafraîchissement stable de 60 FPS.

L'add-on offre une précision bien supérieure à des outils globaux comme Lighthouse pour le débogage de composants individuels.

Timeline

Introduction du module de performance de GitHub

Andres de Better Stack présente le nouveau module complémentaire de GitHub conçu spécifiquement pour l'écosystème Storybook. Cet outil puissant transforme la manière dont les développeurs testent la performance en offrant un panneau d'analyse extrêmement détaillé. Les mesures incluent le timing des images, la stabilité de la mise en page, le profilage React et la pression mémoire. Cette introduction souligne que l'objectif est d'extraire des analyses précieuses pour optimiser le rendu. La vidéo promet une exploration profonde de ces fonctionnalités pour améliorer la réactivité des interfaces.

Le paradigme Shift-Left et les métriques de base

Cette section explique le concept de test de performance "shift-left", qui consiste à intégrer les tests plus tôt dans le cycle de développement. L'outil permet de visualiser l'interaction des composants avec le moteur de rendu du navigateur en temps réel. Le narrateur détaille des phénomènes techniques comme le "jitter", qui cause des animations saccadées, ainsi que le brassage du DOM. On y apprend que l'agitation du DOM survient lorsque le navigateur doit recalculer la mise en page plusieurs fois suite à des modifications de style rapides. Ces données permettent de prendre des décisions architecturales avant même d'arriver en phase de production.

Compatibilité framework et métriques avancées

Le module est polyvalent et s'adapte aussi bien à React qu'à d'autres frameworks comme Vue, Svelte ou les composants Web standard. Pour les utilisateurs de React, il met en lumière les cascades de rendu causées par des changements d'état accidentels. Une métrique cruciale mentionnée est la durée P95, qui reflète l'expérience des utilisateurs ayant les machines les plus lentes. L'utilisation sur les navigateurs Chrome ou Edge est recommandée pour obtenir une fidélité de mesure optimale. Cette flexibilité garantit que l'outil reste utile peu importe la pile technologique choisie par l'équipe de développement.

Démonstrations pratiques et signaux d'alerte

L'auteur utilise un manuel interactif pour illustrer des exemples concrets comme une boîte animée et une liste lourde à filtrer. Dans le cas de la liste, des signaux d'alerte apparaissent tels qu'un décalage de mise en page cumulatif (CLS) élevé et un pic de brassage du DOM. Ces problèmes entraînent des pertes d'images et nuisent gravement à la fluidité perçue par l'utilisateur final. L'exemple du timing d'élément montre comment mesurer précisément le moment où un appel à l'action devient visible. Ces démonstrations prouvent que l'outil identifie les causes exactes des ralentissements dans des scénarios d'utilisation réels.

Analyse du blocage et optimisation par mémoïsation

Cette partie traite des rendus coûteux et de l'impact du JavaScript lourd sur le thread principal du navigateur. Le Temps de Blocage Total (TBT) est présenté comme un avertissement majeur car il empêche toute interaction utilisateur comme le clic ou le défilement. La comparaison entre un composant non optimisé et un composant mémoïsé démontre une économie de travail massive pour le processeur. En évitant les rendus redondants, on libère des ressources précieuses pour maintenir un taux stable de 60 images par seconde. La mémoïsation correcte devient ainsi une solution visible et quantifiable grâce aux graphiques de l'add-on.

Cas d'usage complexes : Cascades et agitation de style

Le narrateur explore les dangers de l'utilisation de "set state" à l'intérieur d'un crochet "use layout effect". Cette pratique force React et le navigateur à effectuer un double travail de calcul avant même que l'utilisateur ne voie le premier pixel. Un autre exemple frappant montre l'agitation de style générée par la modification simultanée de 600 nœuds DOM. Le thread principal est alors saturé, ce qui provoque des avertissements de blocage et une chute drastique de la performance. Ces exemples techniques avancés servent à éduquer les développeurs sur les erreurs de codage courantes qui dégradent l'expérience utilisateur.

Conclusion et comparaison avec Lighthouse

Pour conclure, Andres souligne la différence entre cet add-on et des outils globaux comme Lighthouse. Tandis que Lighthouse donne un score général, ce nouveau panneau offre une précision chirurgicale pour isoler l'impact de composants individuels. Il encourage vivement la communauté à intégrer cet outil dans leur suite Storybook pour obtenir une vision complète du fonctionnement "sous le capot". La vidéo se termine par une invitation à partager ses propres méthodes de mesure de performance en commentaire. C'est un appel à l'action pour adopter une culture de la performance plus rigoureuse et détaillée.

Community Posts

View all posts