React DevTools Profiler

Stop Guessing, Start Measuring

Here's a hard truth: most React performance work is just educated guessing. "I think this component re-renders too much." "That list feels slow." The Profiler replaces all that guesswork with hard data. It tells you exactly what rendered, why, and how long it took.

// You think this component is slow. Is it?
function Dashboard() {
  const [data, setData] = useState(null);
  // ... 20 child components

  return (
    <div>
      <Header />
      <Sidebar />
      <ChartGrid data={data} />
      <ActivityFeed />
    </div>
  );
}

// The Profiler will tell you:
// - Header took 0.2ms (not a problem)
// - Sidebar took 0.5ms (not a problem)
// - ChartGrid took 180ms (THE problem)
// - ActivityFeed took 1.2ms (not a problem)

Without profiling, you might waste time optimizing Header and Sidebar. With profiling, you go straight to ChartGrid.

The Mental Model

Setting Up the Profiler

1. Install React DevTools

React DevTools is available as a browser extension (Chrome, Firefox, Edge) or as a standalone app. After installing, you'll see "Components" and "Profiler" tabs in your browser devtools.

2. Enable "Why did this render?"

In React DevTools settings (gear icon):

• Check "Record why each component rendered while profiling"
• This adds render reason information to the flamegraph

3. Profile a User Interaction

1. Open the Profiler tab
2. Click the Record button (blue circle)
3. Perform the interaction you want to measure (click, type, navigate)
4. Click Stop recording
5. Analyze the results

The Flamegraph

The flamegraph shows every component that rendered, organized by tree structure:

Commit #1: 145ms
┌──────────────────────────────────────────────┐
│ App (2.1ms)                                   │
├──────────────────────────────────────────────┤
│ Header (0.3ms) │ Main (140ms)                │
│                │                              │
│                ├─────────────────────────────┤
│                │ SearchBar │ ChartGrid        │
│                │ (1.2ms)   │ (135ms)         │
│                │           │                  │
│                │           ├────┬────┬───────┤
│                │           │C1  │C2  │C3     │
│                │           │45ms│45ms│45ms   │
└──────────────────────────────────────────────┘

Color coding:

• Gray: Component didn't render (was skipped by memo or bailout)
• Blue-green: Fast render (< 5ms)
• Yellow: Medium render (5-50ms)
• Orange-red: Slow render (> 50ms)

Wide bars mean long render times. Gray bars mean the component was correctly skipped.

The Ranked Chart

This is where you should start every investigation. The ranked chart sorts components by render time, most expensive first:

Ranked Chart — Commit #1
1. ChartGrid         135.2ms
2. Chart (x3)         45.0ms each
3. DataTable           8.5ms
4. SearchBar           1.2ms
5. Header              0.3ms

This immediately tells you where to focus optimization efforts. Don't optimize Header (0.3ms) when ChartGrid takes 135ms.

"Why Did This Render?"

This is the killer feature. When enabled, the Profiler shows the reason each component rendered:

This is the most valuable diagnostic. If a component renders because "the parent rendered" and it produces the same output, that's a candidate for React.memo. If it renders because "props changed: onClick" and onClick is an inline function, you need useCallback.

Interpreting Results

Finding Wasted Renders

Look for components that:

1. Render frequently (many commits show them as colored, not gray)
2. Are expensive (wide bars in flamegraph)
3. Render because of parent, not their own state/props

These are your optimization targets.

Finding Slow Components

Look for:

1. Components with render times > 16ms (causing dropped frames)
2. Components that account for > 50% of the commit time
3. Components with many rendered children (high subtree cost)

Comparing Before/After

Profile before optimization. Save screenshots. Profile after optimization. Compare:

• Did the target component's render time decrease?
• Did the number of renders decrease?
• Did the total commit time decrease?

If not, the optimization didn't help. Remove it to avoid unnecessary complexity.

function onRender(id, phase, actualDuration) {
  // Send to analytics
  analytics.track('react_render', { component: id, duration: actualDuration });
}

<Profiler id="ChartGrid" onRender={onRender}>
  <ChartGrid data={data} />
</Profiler>

The React Profiler Component

For production measurement, use the built-in <Profiler> component:

import { Profiler } from 'react';

function onRender(
  id,              // "ChartGrid"
  phase,           // "mount" | "update"
  actualDuration,  // Time spent rendering the committed update
  baseDuration,    // Time for the entire subtree without memoization
  startTime,       // When React started rendering
  commitTime       // When React committed the update
) {
  if (actualDuration > 16) {
    console.warn(`Slow render: ${id} took ${actualDuration}ms`);
  }
}

function Dashboard() {
  return (
    <Profiler id="Dashboard" onRender={onRender}>
      <ChartGrid />
    </Profiler>
  );
}

baseDuration is particularly useful: it shows how long the render would take without any memoization. Comparing actualDuration to baseDuration tells you how much your memoization is saving.

Production Scenario: Systematic Performance Investigation

"The app is slow." You've heard it. We've all heard it. Here's how you actually investigate instead of randomly adding React.memo everywhere:

1. Reproduce: Identify the specific interaction that feels slow
2. Profile: Record the interaction in the Profiler
3. Identify: Find the slowest component in the ranked chart
4. Diagnose: Check "Why did this render?" — is it necessary?
5. Fix: Apply the appropriate optimization
6. Verify: Profile again. Compare before/after

Investigation log:
- Interaction: typing in search box
- Commit time: 180ms per keystroke
- Ranked chart: ProductGrid (150ms), ProductCard x200 (0.7ms each)
- Why rendered: "Parent component rendered" for all ProductCards
- Diagnosis: ProductGrid re-renders 200 cards on every keystroke
- Fix: React.memo on ProductCard + useMemo for filtered products
- After: Commit time 15ms (12x improvement)

Common Mistakes

Challenge

Challenge: Interpret the profiler output

Profiler output for a single commit (user typed 'a' in search):

Flamegraph:
  App (0.5ms)
  ├── SearchBar (0.8ms) — "State changed: query"
  ├── FilterPanel (0.3ms) — "Parent component rendered"
  ├── ProductGrid (165ms) — "Props changed: products"
  │   ├── ProductCard (0.7ms) × 200 — "Parent component rendered"
  │   └── LoadMoreButton (0.1ms) — "Parent component rendered"
  └── Footer (0.2ms) — "Parent component rendered"

Total commit time: 167ms

Questions:
1. What is the primary performance bottleneck?
2. Which renders are wasted?
3. What specific optimizations would you apply?
4. What would the commit time be after optimization?

Quiz

Key Rules