Leistungsvergleich von React-Komponenten: Gravity UI vs. andere Bibliotheken

Ich bin Core-Entwickler von Gravity UI, und in unserem Team erreichen uns regelmäßig Fragen zur Performance von React-Komponenten aus unserer Bibliothek @gravity-ui/uikit. Ich habe beschlossen, dazu eine kleine Untersuchung zu machen, und alles, was unten steht, ist ein Ausgangspunkt für weitere Untersuchungen und der Versuch, die Frage zu beantworten, warum Gravity langsam ist.

Üblicherweise wird diese Anfrage ohne zusätzliche Details gestellt, daher gehe ich von der Annahme aus, dass eines (wenn auch natürlich nicht das einzige) der Hauptprobleme der Performance eine lange Renderzeit ist. Im Rahmen dieser Untersuchung haben wir die Kosten des ersten Renderings einzelner Komponenten jeder Bibliothek in einer isolierten Umgebung betrachtet. Für den Vergleich wurden die Bibliotheken @adobe/react-spectrum, @mui/material und antd ausgewählt.

Methodik der Untersuchung

Technischer Stack:

• Playwright — ein Framework zur Automatisierung von Tests in verschiedenen Browsern.
  Mehr dazu
• PerformanceObserver API — ein Browser-API zur Messung der Performance.
  Mehr dazu

Bedingungen für die Testausführung:

• Jeder Test wird in einem separaten Browser-Kontext ausgeführt.
• Es wird jeweils nur ein Test gleichzeitig ausgeführt (Einstellung workers in der Playwright-Konfiguration), was garantiert, dass jedem Test die gleiche Menge an Ressourcen zugewiesen wird.
• Jeder Test wird 50-mal wiederholt.
• Die Tests werden mit unterschiedlicher Anzahl von Nodes (10, 100, 1000) durchgeführt.

Ablauf eines Tests:

• Öffnen einer neuen Seite im Browser.
• Initialisierung des PerformanceObserver.
• Start der Erfassung der Metriken.
• Rendern der Komponenten.
• Beenden der Erfassung der Metriken.

Messprozess:

Zu Beginn jedes Tests wird ein PerformanceObserver erstellt, der Ereignisse vom Typ 'measure' verfolgt. Alle gesammelten Metriken werden im globalen Objekt __PERFORMANCE_METRICS__ gespeichert. Der Observer sammelt automatisch Daten über die Ausführungszeit von Operationen, einschließlich des Namens der Metrik, des Ereignistyps, der Startzeit und der Dauer. Mithilfe des Ereignisses measure protokollieren wir unsere Messung total-render-time.

Ergebnisse

Die Messergebnisse enthalten keine absoluten Zahlen. Je nach Umgebung können sie sich natürlich unterscheiden. Aber diese Zahlen reichen vollkommen aus, um einige Abhängigkeiten zu erkennen und darauf basierend Schlussfolgerungen zu ziehen:

• @gravity-ui/uikit zeigt konkurrenzfähige Ergebnisse:

  • Befindet sich in den meisten Tests im oberen Bereich des Rankings.
  • Zeigt eine stabile Renderzeit bei unterschiedlicher Node-Anzahl.
  • Besonders effizient bei den Komponenten Button, Checkbox und Switch.
  • Hat Probleme mit der Renderzeit der Komponente TextArea.

• @mui/material zeigt ebenfalls gute Ergebnisse:

  • Führt bei einer kleinen Anzahl von Nodes fast in allen Kategorien (z. B. Text, Label).
  • Zeigt einen sichtbaren Anstieg der Renderzeit in Abhängigkeit von der Node-Anzahl.

• antd und React Spectrum:

  • Zeigen in den meisten Tests eine höhere Renderzeit.
  • Haben eine größere Streuung zwischen minimaler und maximaler Zeit.

Mit diesem Tool kann man Performance-Messungen auf der eigenen lokalen Maschine durchführen und außerdem Tests für Komponenten hinzufügen, die es noch nicht gibt. Es hilft uns, wenn ihr es bei euch aufsetzt und das Ergebnis eurer Messungen auf eurem Rechner in einem PR einsendet.

In diesem Artikel habe ich eines der Beispiele gezeigt, wie wir mit der Bibliothek arbeiten. Aber Feedback aus der Community ist uns sehr wichtig: Wenn ihr ein konkretes Beispiel habt, in dem Gravity UI deutlich schlechter abschneidet als andere Bibliotheken, oder wenn ihr einen Fehler in unserer Testmethodik seht, kommt in die Kommentare zu diesem Beitrag oder erstellt ein Issue — dann diskutieren wir das. Und vergesst außerdem nicht, dem Projekt Sterne zu geben!