A React 19 app wraps a state update in startTransition, but the page still freezes for roughly 150 ms on every update because one component's render function runs an expensive synchronous computation. Why does marking the update as a transition fail to keep the page responsive here?

## What the transition actually promised Marking an update as a transition tells React that this update is not urgent: React may render it in the background, may interrupt that render if something urgent arrives, and may abandon and redo it. What it never promised is that any individual piece of work becomes interruptible. Priority decides *which* work runs and *whether the walk can be stopped between steps*; it has no power over a function that is already executing. ## Where the yield points are React's concurrent work loop looks conceptually like this: ```js while (workInProgress !== null && !shouldYield()) { workInProgress = performUnitOfWork(workInProgress); } ``` The check happens between iterations. Each iteration is one unit of work — one node of the work tree — and for a function component that unit includes calling your component function and reconciling what it returns. There is no check inside `performUnitOfWork`, and there could not be: JavaScript runs a call to completion, so once React has entered your component body, neither React nor the browser can take the thread back until it returns. So the yield granularity is exactly "one component render". React converts one enormous indivisible block into many small indivisible blocks. If the smallest block is itself 150 ms, the conversion has bought nothing. ## Reading the symptom correctly The telltale distinction is where the time is spent: - **Cost spread across the tree** — ten thousand cheap components, each a fraction of a millisecond. React yields every few milliseconds, input stays responsive, and the update simply lands over several frames. This is what concurrent rendering is for. - **Cost concentrated in one node** — one component that sorts a huge array, formats a giant string, or parses something on every render. React reaches that node, yields nothing for 150 ms, and drops frames. No scheduling API fixes it. A profiler makes this obvious: in the first case the long task is chopped into slices; in the second there is one long task with a single component's render dominating it. ## What actually fixes it Since the constraint is that a single call cannot be split by the scheduler, every real fix either removes the work from the render path or splits it yourself: - **Do not compute it during render.** If the result depends only on inputs that rarely change, compute it once when those inputs change rather than on every pass. - **Move it off the main thread.** A Web Worker runs the computation on another thread and posts the result back; the component then renders a cheap value. This is the only option that removes the cost from the frame entirely. - **Chunk it yourself.** Compute a slice per pass and keep partial results in state, so each render does bounded work — you are re-creating, at your own granularity, what React does between fibers. - **Compute less.** Often the honest answer: the component is formatting ten thousand rows when only the visible slice matters. Note what is *not* a fix: switching to a different scheduling hook, wrapping the update differently, or forcing a synchronous flush. All of them still have to run your function once, in full, on the main thread. ## The distinction interviewers are testing This question separates people who have used a concurrent API from people who know what it changes in the pipeline. The framework's leverage is over *scheduling* — when work starts, in what order, whether it can be dropped. It has no leverage over the *duration* of a single synchronous call. If your component takes 150 ms, every framework on the planet will take 150 ms, and the responsibility to break that up is yours. ## A related trap The same reasoning explains why a slow render is not made safe by lowering its priority for the user's benefit: a background render still occupies the main thread while it runs. Lower priority means the browser gets the thread back *between* units and urgent work jumps ahead — it does not mean the work happens somewhere else.