React DevTools Profiler nutzen

Bisher haben wir Re-Renders mit einem selbstgebauten RenderCounter sichtbar gemacht – nützlich, aber grob. Der React DevTools Profiler ist das offizielle Werkzeug für dieselbe Frage, mit erheblich mehr Detail: WAS hat wie lange gerendert, WARUM wurde eine bestimmte Komponente neu gerendert, und wie verteilt sich die Zeit über den gesamten Baum.

Installation

Installieren Sie die Browser-Erweiterung "React Developer Tools" (Chrome, Firefox oder Edge – jeweils im offiziellen Add-on-Store zu finden). Öffnen Sie danach die Browser-DevTools (F12) in unserer laufenden App – zwei neue Tabs erscheinen: "⚛️ Components" und "⚛️ Profiler".

Achtung: Der Profiler-Tab funktioniert nur im DEVELOPMENT-Build (npm run dev), nicht im produktiven Build (npm run build) – React entfernt die dafür nötigen Zusatz-Informationen bewusst aus dem Produktions-Bundle, um es kleiner und schneller zu machen.

Die erste Aufnahme

"⚛️ Profiler"-Tab öffnen
Den blauen Aufnahme-Kreis (⏺) klicken – er wird rot, die Aufnahme läuft
In der App etwas tun, das einen Re-Render auslöst (z. B. "In den Warenkorb" klicken)
Die Aufnahme mit demselben Knopf wieder stoppen

Nach dem Stoppen erscheint ein "Flame Chart" (Flammendiagramm): jede Zeile ist ein Render-Durchlauf ("Commit"), jeder Balken darin eine Komponente. BREITERE Balken bedeuten LÄNGERE Renderzeit, GRAUE Balken bedeuten "hat NICHT neu gerendert" (React zeigt sie trotzdem zur Orientierung, aber ausgegraut).

"Warum wurde diese Komponente gerendert?"

Klicken Sie auf einen einzelnen, farbigen Balken – ein Seitenpanel zeigt Details, darunter oft "Why did this render?" mit einer Liste der GEÄNDERTEN Props/State-Werte, die den Render ausgelöst haben. Das ist der direkte, werkzeuggestützte Ersatz für unser manuelles RenderCounter-Experiment aus Kapitel 27 – aktivieren Sie dafür in den Profiler-Einstellungen (Zahnrad-Symbol) die Option "Record why each component rendered while profiling".

Praxis-Experiment: CartWidget im Profiler beobachten

Starten Sie eine neue Aufnahme, klicken Sie zweimal "In den Warenkorb" bei DEMSELBEN Produkt, stoppen Sie die Aufnahme. Sie sollten sehen: ProductCard selbst rendert NICHT neu (sein isFavorite-State ändert sich nicht), aber CartWidget UND ProductListPage rendern jeweils neu. Klicken Sie auf den CartWidget-Balken und lesen Sie die "Why did this render"-Begründung – sie sollte den geänderten useSelector-Rückgabewert (die Artikelanzahl) als Ursache nennen.

Den "Ranked"-Modus nutzen

Oben im Profiler-Panel gibt es einen Umschalter zwischen "Flamegraph" und "Ranked". Der Ranked-Modus sortiert ALLE Komponenten eines Commits nach Renderzeit, absteigend – ideal, um in einer großen App SCHNELL die "teuersten" Komponenten eines bestimmten Updates zu finden, ohne den ganzen Baum durchsuchen zu müssen.

Interaktionen live verfolgen statt manuell aufzeichnen

Alternative zum manuellen Start/Stopp: der kleine Kreis-Button neben der Aufnahme-Taste aktiviert "Reload and start profiling" – nützlich, um auch das ALLERERSTE Rendern der App (direkt nach dem Laden) zu profilen, was durch manuelles Starten nach dem Laden immer verpasst wird.

Tipp: Faustregel für den Profiler-Einsatz: NICHT bei jeder Komponente vorsorglich optimieren ("premature optimization") – erst PROFILEN, um tatsächliche, messbare Engpässe zu finden, DANN gezielt mit den Werkzeugen der nächsten Kapitel (React.memo, Virtualisierung, Concurrent Features) beheben. Ein Balken, der 0,3ms breit ist, braucht keine Optimierung, egal wie unelegant der Code dahinter aussieht.

Achtung: Denken Sie an <StrictMode> aus main.jsx: im Entwicklungsmodus rendert React manche Komponenten BEWUSST doppelt, um Seiteneffekt-Bugs aufzudecken (siehe "React für Einsteiger" Kapitel 2). Der Profiler zeigt diese doppelten Renders ebenfalls an – verwechseln Sie das nicht mit einem echten Performance-Problem. Im produktiven Build (npm run build) passiert das doppelte Rendern nicht.