Comparaison de performance des composants React: Gravity UI vs autres bibliothèques

Je suis développeur core de Gravity UI, et notre équipe reçoit régulièrement des questions sur les performances des composants React de notre bibliothèque @gravity-ui/uikit. J’ai décidé de mener une petite étude sur ce sujet, et tout ce qui est écrit ci-dessous constitue un point de départ pour de futures recherches ainsi qu’une tentative de répondre à la question: pourquoi Gravity est-il lent?

En général, cette demande est formulée sans détails supplémentaires; je pars donc du principe que l’un des principaux problèmes de performance (même si ce n’est évidemment pas le seul) est un temps de rendu trop long. Dans le cadre de cette étude, nous avons examiné le coût du premier rendu de composants individuels de chacune des bibliothèques dans un environnement isolé. Pour la comparaison, les bibliothèques @adobe/react-spectrum, @mui/material et antd ont été retenues.

Méthodologie de l’étude

Stack technique:

• Playwright — framework pour automatiser les tests de code dans différents navigateurs.
  En savoir plus
• PerformanceObserver API — API du navigateur pour mesurer les performances.
  En savoir plus

Conditions d’exécution des tests:

• Chaque test est lancé dans un contexte de navigateur séparé.
• Un seul test est exécuté à la fois (paramètre workers dans la configuration Playwright), ce qui garantit l’allocation de la même quantité de ressources à chaque test.
• Chaque test est répété 50 fois.
• Les tests sont effectués avec un nombre de nœuds différent (10, 100, 1000).

Déroulement d’un test:

• Ouverture d’une nouvelle page dans le navigateur.
• Initialisation de PerformanceObserver.
• Début de la collecte des métriques.
• Rendu des composants.
• Fin de la collecte des métriques.

Processus de mesure:

Au début de chaque test, un PerformanceObserver est créé; il suit les événements de type 'measure'. Toutes les métriques collectées sont enregistrées dans l’objet global __PERFORMANCE_METRICS__. L’observer collecte automatiquement des données sur le temps d’exécution des opérations, y compris le nom de la métrique, le type d’événement, l’heure de début et la durée. À l’aide de l’événement measure, nous journalisons notre mesure total-render-time.

Résultats

Les résultats des mesures ne contiennent pas de valeurs absolues. D’un environnement à l’autre, ils peuvent bien sûr varier. Mais ces chiffres suffisent amplement pour mettre en évidence certaines tendances et en tirer des conclusions:

• @gravity-ui/uikit affiche des résultats compétitifs:

  • Se situe dans la partie haute du classement dans la plupart des tests.
  • Montre un temps de rendu stable avec un nombre de nœuds différent.
  • Est particulièrement efficace pour les composants Button, Checkbox et Switch.
  • A des problèmes de temps de rendu pour le composant TextArea.

• @mui/material affiche également de bons résultats:

  • Est en tête dans presque toutes les catégories (par ex. Text, Label) avec un petit nombre de nœuds.
  • Montre une augmentation visible du temps de rendu en fonction du nombre de nœuds.

• antd et React Spectrum:

  • Affichent un temps de rendu plus élevé dans la plupart des tests.
  • Présentent une dispersion plus importante entre le temps minimal et maximal.

À l’aide de cet outil, vous pouvez effectuer des mesures de performance sur votre machine locale et ajouter des tests pour des composants qui n’existent pas encore. Cela nous aiderait si vous le déployez chez vous et envoyez dans une PR le résultat obtenu sur votre ordinateur.

Dans cet article, j’ai présenté l’un des exemples de la manière dont nous travaillons avec la bibliothèque. Mais les retours de la communauté sont très importants pour nous: si vous avez un exemple concret où Gravity UI se comporte nettement moins bien que d’autres bibliothèques, ou si vous voyez une erreur dans notre méthodologie de test, venez dans les commentaires de ce billet ou créez une issue — discutons-en. Et n’oubliez pas non plus de mettre des étoiles au projet!