Profiler and measurement: find the 600 ms commit before touching React.memo

Reading the flamegraph: commits, not components

The React DevTools Profiler records a session of interactions and slices it into commits — every time React actually flushed changes to the DOM, you get one bar in the timeline. Selecting a commit shows a flamegraph: each row of the tree is a component, the width of its bar is how long it (plus its children) took to render in that commit, and gray bars are components that did not render at all. This framing matters: the question is never “which component is slow” in the abstract, it is “which commit is slow, and what inside it burned the time”. A 600 ms commit with one wide bar is a different disease than sixty 10 ms commits triggered by a chatty subscription — and they need opposite cures.

Two settings turn the tool from a chart into a diagnosis. “Record why each component rendered” annotates every bar with the cause: props changed (and which ones), state changed, a hook changed, or the parent rendered. That single annotation kills most guesswork — the chart remount in the Hook story showed up as “key changed”, which no amount of staring at component code would reveal. Second, the “Highlight updates” checkbox paints rectangles over everything that re-renders live, which is the fastest way to spot a context provider rerendering half the page on every keystroke. Profile in development first for the rich data, but remember development React is materially slower — confirm any number that drives a decision against a production profiling build (react-dom/profiling), which keeps timing hooks at a few percent overhead.

The Profiler API: numbers you can ship

DevTools is interactive; the <Profiler> component is programmable. Wrap a subtree, and React calls onRender after every commit inside it with timing data you can log, aggregate, or send to your monitoring backend:

import { Profiler } from "react";

function onRender(id, phase, actualDuration, baseDuration, startTime, commitTime) {
  // actualDuration: time spent rendering this commit (with memoization applied)
  // baseDuration: estimated worst case — every descendant rendering, no memo
  metrics.send("react-commit", {
    id,                       // "FilterPanel"
    phase,                    // "mount" | "update" | "nested-update"
    actual: actualDuration,   // e.g. 4.2 (ms)
    base: baseDuration,       // e.g. 38.7 (ms)
  });
}

<Profiler id="FilterPanel" onRender={onRender}>
  <FilterPanel />
</Profiler>

The pair worth internalizing is actualDuration versus baseDuration. actualDuration is what this commit really cost; baseDuration is the sum of each descendant’s most recent render time — an estimate of the worst case where nothing is memoized. When actualDuration sits far below baseDuration, your memoization is earning its keep; when the two track each other, the React.memo wrappers are decoration. That comparison is exactly the evidence the Hook team never collected: their memo campaign moved actualDuration from 42 ms to 38 ms on the commit that mattered — within noise — because the 620 ms remount bypassed memoization entirely. Tradeoff: <Profiler> is cheap but not free (React does extra bookkeeping per commit inside profiled trees), so in production wrap the two or three interactions you actually monitor, not the root.

INP and the 16 ms myth

The number everyone quotes — 16.7 ms, one frame at 60 Hz — is a budget for continuous motion: animation, scrolling, dragging. Miss it during a drag and the user sees stutter. But a click is not an animation. For discrete interactions the user-facing metric is INP (Interaction to Next Paint): from the keypress or click until the next frame paints, including input delay (the main thread was busy when the event arrived), processing (your handlers, React’s render and commit), and presentation delay (style, layout, paint). The thresholds are 200 ms for “good” and 500 ms for “poor” — roughly 12 to 30 frame-budgets, and your page’s INP is approximately its worst such interaction over the visit, not the average.

This is why the 16 ms framing misleads optimization work in both directions. It makes a 30 ms commit on a button click look like a violation worth a refactor, when the user cannot distinguish 30 ms from instant. And it says nothing about the real killer: any main-thread task over 50 ms is a long task that adds input delay to whatever the user does next — a 620 ms commit doesn’t just delay its own interaction, it freezes every click that arrives during it. The operational loop, in order: read INP from field data (it is interaction-specific, so lab numbers on a fast laptop routinely miss it), find the worst interaction, profile that interaction, fix the widest bar, measure again. The Hook team ran this loop backwards — fix first, measure never.