Reading the React DevTools Flamegraph

The plain-language idea

Every other lesson on rendering and memoization has you reasoning about why a component re-renders by reading code. The React DevTools Profiler's flamegraph shows you what actually happened, per commit, for real — instead of predicting it. You record a session, interact with the app, and stop recording; the flamegraph then shows one bar per component that rendered during a chosen commit, with the bar's width and color both telling you something.

Width is proportional to how long that component took to render in that specific commit. Color tells you whether it rendered at all: gray means the component did not render during this commit (React bailed out — usually because of React.memo or because its props/state genuinely didn't change), while yellow/orange shades mean it rendered, with darker/warmer meaning slower relative to everything else in that commit.

See it in a real thing: catching an unnecessary re-render

function App() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <ExpensiveList items={staticItems} />
    </div>
  );
}

staticItems never changes, so ExpensiveList never has a real reason to re-render when the button is clicked — but as written, it will anyway, because App re-rendering re-runs ExpensiveList's render by default. Here's how you'd actually confirm that with the Profiler instead of just suspecting it:

1. Open the Profiler tab, click record, click the button a few times, stop recording.
2. Look at the flamegraph for one of the commits. ExpensiveList shows up with a colored bar — it rendered — even though nothing it actually displays changed.
3. Turn on "Why did this render?" in the Profiler's settings and click ExpensiveList's bar. It reports the reason: the parent (App) re-rendered, and ExpensiveList has no memoization to bail out with.
4. Wrap it: const ExpensiveList = React.memo(function ExpensiveList({ items }) { ... }).
5. Record again, click the button again. ExpensiveList now shows up gray — it didn't render this commit at all. React compared its props (items, still the same reference), found them equal, and skipped it entirely.

That gray-vs-colored difference, before and after, is the direct, visual version of what the memoization lesson describes in prose: a stable reference reaching a component wrapped in React.memo lets React skip the render outright.

What people usually miss

Watch out

• A bar's width is scoped to one commit, not cumulative across the recording. A component that renders constantly but cheaply each time can look "fine" in any single commit's flamegraph while still being the actual problem overall — check it across several commits, or use the summary view at the top, before concluding it's not an issue.
• Gray means "did not render this commit," not "is fast." A component that's genuinely slow but simply didn't render in the commit you're looking at is also invisible — gray isn't a performance verdict, it's a bail-out signal. Don't mistake "nothing shown" for "problem solved" without checking a commit where it did render.
• "Why did this render?" is the fastest way to find the cause — use it before guessing. It's an opt-in setting (a checkbox in the Profiler's gear icon) precisely because it adds instrumentation overhead; turn it on for the debugging session, then back off.

The genealogy: watching reconciliation and memoization happen instead of reasoning about them

Every bar in this flamegraph is a direct visualization of two things covered earlier: reconciliation deciding a component needs to re-render, and memoization deciding whether that render can be skipped. The colored-versus-gray difference on ExpensiveList before and after wrapping it in React.memo isn't a new mechanism — it's the exact mechanism from those lessons, just rendered as a picture instead of something you have to trace through code in your head.