React Profiler, the Compiler, and production observability

Users report lag. The app feels fine in the office. The Profiler shows a 38 ms commit triggered by a keystroke in a search box — and 240 ProductCards re-rendering with reason “parent rendered, props unchanged.” That is the bug signature. Without the Profiler, you are guessing; with it, the fix is mechanical.

Reading the React Profiler. The React DevTools Profiler records a commit-by-commit timeline. For each commit it shows which fibers rendered, why each rendered (“props changed”, “hook changed”, “parent rendered”, “context changed”), and how long each took. The senior workflow: record an interaction, find the commit that is too long, sort fibers by self-time, and read the “why did this render” reason.

• “Parent rendered” on unchanged props → missing bailout. Wrap in React.memo, stabilise the offending prop reference.
• “Context changed” across many components → unstable context value. Memoise the provider’s value with useMemo.
• “Hook changed” → a useState or useReducer value that changed. Check if the computation producing it is memoised.

Commit #47  —  render: 38.2 ms  (1 of 1 committed)

<App>                rendered  — 0.4 ms  — "hook changed"
  <Header>           rendered  — 0.2 ms  — "parent rendered"
  <Sidebar>          rendered  — 0.3 ms  — "parent rendered"
  <ProductGrid>      rendered  — 36.9 ms — "parent rendered"
    <ProductCard> x240  rendered  — 0.15 ms each — "parent rendered"

Why did <App> render?  -> useState (searchTerm) changed
Note: <Header>, <Sidebar>, <ProductGrid> props unchanged

Production observability: LoAF + Profiler. The Profiler gives you local reproduction; Long Animation Frames (LoAF) give you production attribution. When a LoAF entry attributes a slow frame to a React bundle, the Profiler reproduces it locally and names the exact fibers. The two together close the loop from “users report lag” to “this component re-renders 200× because of an inline style object on line 44.”

React Compiler and the future of memoisation. For a decade, keeping the bailout firing meant scattering useMemo, useCallback, and React.memo by hand — tedious, error-prone, and itself not free (each memo cell costs memory and a comparison). The React Compiler (formerly “React Forget”, stable-track as of React 19) is a build-time tool that analyses component code and inserts the memoisation automatically and correctly, at finer granularity than a human would. It understands which values depend on which inputs and memoises exactly those, so the bailout fires without any hand-written hooks.

The senior takeaway: the mechanism — referential stability gating the bailout — is not going away; it is the foundation the compiler builds on. Understanding why a stable reference lets a fiber skip work is what lets you read the compiler’s output, debug it when it bails out conservatively, and reason about performance whether the memoisation is hand-written or compiler-generated.

A fiber is where component state lives between renders — the useState values, the refs, the hook list all hang off the fiber, not the component function. Render after render, the fiber persists and carries that state forward; destroy the fiber (unmount, type change, key change) and the state is gone. The reconciler is, at bottom, a machine for deciding which fibers survive and which are rebuilt — the same statefulness question, of what persists across a transition and what is re-derived, that runs through every layer of the stack. ↻ statefulness