React DevTools Profiler Deep Dive

The plain-language idea

Knowing how to read a flamegraph's shape is one skill. Actually producing a useful recording — capturing the right interaction, isolating the right commit, and pulling real numbers out of it instead of an eyeballed guess — is a different, earlier skill, and it's what this lesson covers.

The React DevTools Profiler tab records every commit that happens while it's recording: each state update, each re-render, with a duration attached. You press record, do the exact user interaction you're investigating, stop, and then you have a timeline of every commit that interaction caused — which is the raw material a flamegraph is built from.

See it in a real thing: measuring before and after a fix

The Profiler API lets you do the same measurement in code, which is useful for logging or automated checks:

import { Profiler } from "react";

function onRenderCallback(id, phase, actualDuration, baseDuration) {
  console.log(`${id} (${phase}): actual ${actualDuration.toFixed(2)}ms, baseline ${baseDuration.toFixed(2)}ms`);
}

function App() {
  return (
    <Profiler id="Dashboard" onRenderCallback={onRenderCallback}>
      <Dashboard />
    </Profiler>
  );
}

actualDuration is how long this commit actually took, including any memoization currently in place. baseDuration is React's estimate of how long the subtree would take to render without any memoization at all. The gap between them is what memoization is buying you — if you add memo somewhere and actualDuration drops while baseDuration stays roughly the same, that's a measured win, not a guess.

In the browser extension itself, the same workflow: hit record, perform the interaction, stop, then turn on "Record why each component rendered" in the Profiler's settings gear. That single setting is the highest-value one in the whole tab — it annotates every bar with the actual reason, like "props changed: value" or "hooks changed," turning "something re-rendered" into "this specific prop caused it."

What people usually miss

Watch out

• A standard production build strips profiling data for size, so the Profiler tab won't show meaningful timings against it — you need either a development build or React's dedicated profiling build to get real numbers.
• "Why did this render" is off by default and has to be turned on in the DevTools settings before it starts annotating commits — it's easy to record a session, see bars with no explanation, and assume the feature doesn't exist.
• The absolute millisecond number matters less than whether it changed. A component taking 4ms isn't automatically a problem; what makes a profiling session useful is comparing the same interaction's numbers before and after a change, not judging one number in isolation.

The genealogy: the tool that measures what memoization promises

This is the workflow that turns this track's memoization lesson from theory into evidence — instead of assuming memo or useMemo helped, you record, check the "why did this render" reason, and confirm the duration actually dropped. Once you have a recording worth looking at, this track's lesson on reading a flamegraph's shape is what tells you how to interpret it.