Render and commit: why React calls your component more often than it paints

A render is a function call, not a screen update

Every UI update in React moves through the same pipeline: trigger → render → commit. A trigger is either the initial mount or a state update (setState schedules a re-render; it does not perform one). The render phase is React calling your component functions. The return value is a tree of elements — plain, immutable JavaScript objects produced by JSX (react.createElement under the hood) that describe what the UI should look like: type, props, children. Creating elements is cheap — no DOM is touched, nothing is painted, nothing is measured. React renders the component whose state changed, then recursively renders its children, building a complete description of the next UI.

This is the part that trips people up: a “render” produces a description, and a description can be compared, cached, or thrown in the trash at zero cost to the user. The commit phase is where React takes the difference between the new description and what is currently on screen and applies the minimal set of real DOM mutations — appendChild, attribute updates, removals — in one synchronous, uninterruptible pass. After commit, the browser paints, then passive effects (useEffect) run. Layout effects (useLayoutEffect) run inside commit, after mutation but before paint — which is why they can measure the DOM without the user seeing a flicker, and why slow code there blocks paint directly.

Fiber: the unit of work that makes rendering interruptible

When you look at a React component, you see a function that runs and returns JSX — but internally, every component instance is backed by a fiber — a mutable node holding the component’s type, its current props, its hook state (a linked list — this is why hook order must be stable), and flags describing what changed. The render phase is a work loop over fibers: process one fiber, render its component, reconcile its children, move to the next. One fiber = one unit of work, and between units React can stop. For urgent updates React still runs the loop to completion synchronously, but inside transitions and other concurrent features it yields back to the browser roughly every 5 ms, so a long render of a 2,000-row tree no longer freezes typing for 300 ms — the keystroke handler runs between units of work.

The second structural trick is double buffering: React keeps the current fiber tree (what is on screen) and builds a separate work-in-progress tree during render. Commit is, at its core, swapping the pointer from current to work-in-progress. That separation is what makes discarding work safe: if a higher-priority update arrives mid-render, React abandons the work-in-progress tree — the current tree was never touched, so the screen is still consistent — and starts a fresh render from the new state.

Why render must be pure — and how StrictMode keeps you honest

Purity is not a style preference; it is the contract that makes the scheduler legal. Given the same props and state, your component must return the same elements and change nothing else — no mutating objects that existed before the call, no network requests, no writing to refs, no analytics.track. The reason is arithmetic: render may run zero, one, or many times per committed frame. A transition render can be discarded and restarted; a future offscreen render may run for UI that never becomes visible. A side effect in render therefore fires an unpredictable number of times — the Hook’s 40% phantom impressions were exactly this, side effects from renders that never committed.

function SearchResults({ items, query }) {
  // Bug: render-phase side effect. Fires once per render *attempt* —
  // including renders React discards — not once per paint.
  analytics.track("impression", { query });

  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

function SearchResultsFixed({ items, query }) {
  // Effects run after commit — once per *committed* change of query.
  useEffect(() => {
    analytics.track("impression", { query });
  }, [query]);

  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

StrictMode is the enforcement tool: in development it deliberately invokes each component’s render twice (and re-runs effect setup/cleanup once on mount) so that any impurity produces a visible double — two logs, two requests, a mutated array growing twice. Pure components are unaffected by the double call, which is the whole test. Tradeoff: purity forbids doing work in the most “obvious” place and forces it into event handlers and effects, which feels bureaucratic on day one — but it is what buys interruptible rendering, render caching, and server rendering for free. Failure mode: teams that disable StrictMode “because it logs twice” are switching off the only alarm that fires before the production incident.