Transitions and useDeferredValue: making slow renders interruptible, not faster

Two lanes: urgent and non-urgent

startTransition does not speed anything up, debounce anything, or move work off the main thread. It changes the priority of the state updates inside its callback: they become transitions — non-urgent updates that React renders in the background while the screen keeps showing the last committed UI. Urgent updates (typing, clicking, anything not wrapped) interrupt that background render: React abandons the half-built work-in-progress tree, commits the urgent update first, then restarts the transition render from the latest state. During the background render React also yields to the main thread between components (roughly every 5 ms), so the browser can paint and handle events mid-render instead of freezing for the full 280 ms.

function CatalogSearch({ products }) {
  const [text, setText] = useState("");        // urgent: echoes the keystroke
  const [query, setQuery] = useState("");      // transition: drives the heavy list
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    setText(e.target.value);                   // commits immediately
    startTransition(() => {
      setQuery(e.target.value);                // renders in background, interruptible
    });
  }

  return (
    <>
      <input value={text} onChange={handleChange} />
      <div style={{ opacity: isPending ? 0.6 : 1 }}>
        <ProductGrid products={products} query={query} />
      </div>
    </>
  );
}

The split is the whole design: the urgent state’s render is tiny (one input), so it commits within a frame or two; the expensive tree depends only on the transition state, so its render is interruptible and restartable. isPending gives you an honest loading signal for the stale-but-visible content. The Hook team’s first attempt failed because they had one state doing both jobs — wrapping it in a transition made the input echo non-urgent too. Rule of thumb: the value the user is directly manipulating must never be inside the transition.

useDeferredValue: deferring values you do not own

useTransition requires owning the setState call. Often you do not — the prop comes from a parent, a router, or a library hook. useDeferredValue(value) is the receiving side’s equivalent: it returns the previous value while a background re-render with the new value is in flight, letting you keep an expensive subtree on the stale value without touching the producer.

function SearchResults({ query }) {           // query updates urgently upstream
  const deferredQuery = useDeferredValue(query);
  const isStale = deferredQuery !== query;
  const grid = useMemo(
    () => <HeavyGrid query={deferredQuery} />,
    [deferredQuery]
  );
  return <div style={{ opacity: isStale ? 0.6 : 1 }}>{grid}</div>;
}

Mechanically: when query changes, React first re-renders urgently with deferredQuery still holding the old value — this render must be cheap, which is why the expensive subtree is memoized on deferredQuery and bails out — then starts a background render where deferredQuery catches up. That background render is a transition: interruptible, restartable on the next change. The memoization is not optional decoration here; without it the urgent render re-renders HeavyGrid with the old value anyway, and you pay the full cost twice per keystroke. Choosing between them: own the setter → useTransition (plus isPending for free); receive the value → useDeferredValue (compare values for staleness).

Transitions and Suspense: no fallback flash

The second superpower is what transitions do to Suspense. An urgent update that suspends — say, changing a tab makes a component throw a promise for data it does not have — hides the already-visible content behind the nearest fallback: the page you were reading is replaced by a spinner. The same update inside a transition behaves differently: React keeps the current, committed UI on screen, renders the suspended tree in the background, and commits only when the data is ready. No fallback flash; the old tab stays visible (use isPending to dim it). This is why router navigations in modern frameworks are wrapped in transitions by default — clicking a link should not blank a working page into a spinner. The exception is precise: only already revealed content is protected. A Suspense boundary mounting for the first time inside the transition still shows its fallback — there is no previous UI to hold.

When transitions do nothing

Transitions buy you interruptibility between components, applied to render-phase work. Three situations defeat them. One giant component: React yields between component renders, never inside one — a single component that takes 200 ms (a monolithic chart building 10,000 SVG elements in one function) blocks the lane regardless of priority; break it into smaller components or virtualize. The cost is not render: if the slowness is a synchronous filter over 100k items inside the event handler itself, or layout thrash in effects, the work happens outside the render phase that transitions schedule. One cheap commit: if the update was a 20 ms render committing once, there is nothing to slice — wrapping it changes nothing observable. A transition is a scheduler hint, not a speedup: total CPU work is identical or slightly higher (abandoned renders are paid for and thrown away — that is the deal: wasted watts for responsive input).