Lesen von React-Performance-Daten in den Chrome DevTools, um langsame Darstellungen zu finden

Wenn eine Interaktion in React träge erscheint, ist die erste Reaktion, useMemo, useCallback und React.memo hinzuzufügen und zu hoffen. Oft bleibt die Seite weiterhin langsam, weil niemand gemessen hat, was die Zeit in Anspruch nimmt. React 19.2 fügte Performance Tracks hinzu, die die Aktivitäten von React in die Leistungszeitlinie des Browsers schreiben; hier wird erklärt, was jede Spur anzeigt und wie man eine Aufzeichnung in eine gezielte Lösung umwandelt.

Warum die einfache Zeitlinie schwer zu lesen war

Führt man eine langsame Interaktion im Performance-Panel der Chrome DevTools in einer Anwendung ohne diese Tracks auf, sieht der Hauptthread in der Regel so aus:

JavaScript
████████████████████
██████████
███
████████████

JavaScript ist offensichtlich beschäftigt, aber welcher Komponente lag das zugrunde, welche Aktualisierung hat die Darstellung gestartet, wartete die Seite auf Netzwerkdaten, hatte ein Effect Vorrang, und hat React genau dann gerendert, als der Benutzer auf sofortige Rückmeldung wartete? Der allgemeine Überblick lässt einen dies aus den Funktionsnamen erschließen müssen. Die React-Tracks liefern den fehlenden Kontext.

Was die React-Tracks hinzufügen

React stellt spezielle Tracks für drei Bereiche bereit:

Scheduler
Components
Server

Sie befinden sich neben den üblichen Spuren des Browsers, sodass eine einzelne Spur ungefähr so gelesen werden kann:

USER CLICK
    │
    ▼
┌─────────────────────────────┐
│ React Scheduler             │
│ Blocking → Render → Commit  │
├─────────────────────────────┤
│ React Components            │
│ Dashboard                   │
│ ├─ Header                   │
│ ├─ DataTable  ← expensive   │
│ └─ Chart                    │
├─────────────────────────────┤
│ Network / JavaScript        │
└─────────────────────────────┘

Der Wert liegt in der Korrelation: Die Aktivitäten von React und des Browsers erscheinen auf einer gemeinsamen Zeitachse.

Scheduler: Warum wurde diese Aufgabe jetzt ausgeführt?

React behandelt nicht jeden Update auf dieselbe Weise. Der Scheduler trennt die Aufgaben nach Priorität, mit Bereichen wie Blocking, Transition, Suspense und Idle, und kennzeichnet die Phasen jedes Updates: Update, Render, Commit sowie alle verbleibenden Effects.

Dadurch lässt sich eine Frage wie „Warum gibt es Verzögerungen beim Eingeben in dieses Feld?“ beantworten. Die Trace kann zeigen, dass eine Tasteneingabe einen aufwendigen synchronen Render im Blocking-Bereich ausgelöst hat. Oder sie kann zeigen, dass die teure Aufgabe bereits richtig in einen Transition-Bereich eingebettet war, was Sie auf eine andere Stelle hinweist. In jedem Fall arbeiten Sie anhand von Beweisen statt auf Intuition. Falls Transitions und Prioritäten neu für Sie sind, wird das Modell hinter diesen Bereichen in Understanding React Lanes erläutert.

Komponenten: Wer hat die Arbeit erledigt?

Zur täglichen Fehlersuche ist dies in der Regel der nützlichste Ansatz. Er zeigt in einem Flamegraph an, wie lange jede Komponente für das Rendern und Ausführen von Effekten benötigt hat, und kann in der Entwicklung außerdem geänderte Eigenschaften sowie kaskadierte Aktualisierungen hervorheben. Ein solches Ergebnis ist typisch:

ProductPage        310ms
├── Header           12ms
├── Filters          18ms
├── DataTable       245ms  ←
└── Footer            8ms

Anstelle der vagen Beschwerde, dass React langsam sei, haben Sie nun eine genaue Spur: DataTable hat den größten Teil des Renderings in Anspruch genommen. Prüfen Sie anschließend, ob es zu viele Zeilen rendernt, die Daten bei jedem Durchlauf neu berechnet oder jedes Mal neue Eigenschaften von seinem Elternteil erhält.

Server: Wartet die Seite überhaupt auf React?

In Anwendungen, die React Server Components verwenden, werden in den Entwicklungsversionen zusätzlich Serveranfragen sowie die Arbeit der Serverkomponenten im Zeitverlauf angezeigt. Dadurch wird eine häufige Fehldiagnose aufgedeckt:

Slow page
   │
   ▼
Assume React render
   │
   X
   │
   ▼
Actually waiting on:
getProducts()
      │
      ▼
Database / API

Falls die Überwachung zeigt, dass die Seite untätig bleibt, während getProducts() auf eine Datenbank oder ein API wartet, liegt die Lösung in der Datenerfassung – beispielsweise durch Caching, parallele Anfragen oder effizientere Abfragen. Das Einhüllen von Komponenten in React.memo hilft dabei nicht. Genau deshalb sollte die gesamte Ausführungszeitlinie in einem einzigen Überblick dargestellt werden.

Ein wiederholbarer Debugging-Ablauf

Wenn eine Interaktion langsam erscheint, befolgen Sie jedes Mal dieselbe Abfolge:

1. Reproduce the problem
          ↓
2. Open Performance
          ↓
3. Record the interaction
          ↓
4. Find the slow React work
          ↓
5. Inspect the component / phase
          ↓
6. Check network and browser work
          ↓
7. Fix the actual bottleneck
          ↓
8. Record again

Überspringen Sie den letzten Schritt nicht. Aufnehmen Sie erneut unter denselben Bedingungen und vergleichen Sie die Ergebnisse. Eine Optimierung, die nie erneut gemessen wurde, bleibt lediglich eine Hypothese – manchmal zeigt die zweite Überwachung, dass sich der Aufwand an einer anderen Stelle verlagert hat, anstatt beseitigt zu werden.

Kennen Sie die Grenzen einer lokalen Überwachung

Performance-Tracks dienen als Hilfsmittel für die Entwicklung und Profilierung. React weist darauf hin, dass die Instrumentierung Overhead verursacht und in Produktionsversionen standardmäßig deaktiviert ist, während die Server-Tracks nur in Entwicklungsversionen verfügbar sind. Entwicklungsversionen laufen außerdem insgesamt langsamer, weshalb Prozentsätze wichtiger sind als absolute Zahlen.

Das bedeutet, dass ein sauberer Trace auf Ihrem Rechner nicht beweist, dass echte Nutzer eine schnelle Erfahrung haben. Für die Leistung in der Produktion sind weiterhin Felddaten sowie die Überwachung echter Nutzer erforderlich. Die Tracks beantworten eine engere, aber sehr praktische Frage: Was macht die Anwendung Schritt für Schritt, während Sie dieses spezifische Problem nachstellen?

Haupterkenntnisse

Die kostspieligste Leistungsangewohnheit besteht nicht darin, den falschen Hook zu wählen; vielmehr liegt sie im Optimieren, bevor das Problem verstanden wurde. Ein soliderer Ansatz sieht so aus:

Slow interaction
       │
       ▼
    Measure
       │
       ▼
 Find the bottleneck
       │
 ┌─────┼──────┐
 ▼     ▼      ▼
React Network Browser
 │      │      │
 ▼      ▼      ▼
Fix    Fix    Fix

• Messen zuerst: Die Spuren machen das Aufzeichnen und Finden des Engpasses zum einfachen Teil.
• Nutzen Sie die Scheduler-Spur, um Prioritäten und Phasen zu verstehen, sowie die Components-Spur, um den ressourcenintensiven Unterbaum zu finden.
• Überprüfen Sie die Server-Spur sowie die Netzwerkkanäle, bevor Sie annehmen, dass das Renderen schuld ist.
• Erneut aufzeichnen nach jeder Änderung, um die Behebung zu bestätigen.
• Betrachten Sie lokale Spuren als Diagnosehilfe und verlassen Sie sich auf Felddaten, um herauszufinden, was die Benutzer erleben.

Auf diese Weise verschiebt sich das Gespräch von der Frage, ob useMemo hinzugefügt werden soll, hin zu dem, was tatsächlich die 200 Millisekunden in Anspruch genommen hat – und genau diese Frage führt zu einer echten Lösung.