A server-rendered React page paints in under a second but stays unresponsive for several seconds afterwards while hydration runs. As the engineer who owns this page, how do you reason about hydration cost, and what tradeoffs do you weigh in reducing it?

## Start by naming the cost model The symptom — fast paint, dead page — is not mysterious once the model is explicit. Hydration removes DOM construction from the critical path and removes nothing else. Downloading and parsing the bundle, calling every client component function, running every hook initializer, building the tree in memory, and running effects all happen on the main thread after the pixels are already up. Two consequences follow immediately, and stating them is what separates a systems answer from a list of tips: - **Cost is proportional to the client tree, not to the viewport.** Content the user will never scroll to hydrates on exactly the same terms as the hero. Lazy-loading images does nothing for this bill. - **The work is largely non-negotiable per component.** You cannot memoize your way out of hydration; memoization affects *subsequent* renders, and hydration is the first one. Every component in the client tree runs once, no exceptions. ## Measure before you cut A lead who reorganises a page on intuition usually moves the cost around. What I want before touching architecture: - **Real-user interaction latency**, not lab numbers. The gap only exists on the devices and networks your users actually have; a fast laptop hides it completely. - **Long tasks during hydration** in field data, to see whether the main thread is blocked in one long block or many short ones. One long block is a structural problem; many short ones may already be yielding acceptably. - **An inventory of the client tree.** Which parts of this page are in the client bundle, and which of those are actually interactive? On most pages the honest answer is that a large share of the tree exists only to display text. ## The levers, in order of payoff **Ship less client tree.** The largest wins are always deletions: content that only renders markup and never handles an interaction does not need to be part of the client tree at all. This is a structural decision about where the client boundary sits, and it dominates every micro-optimisation. **Split what remains, so order matters.** Breaking the tree into independently hydratable regions behind Suspense boundaries lets React hydrate in chunks, yield to the browser between them, and prioritize whichever region the user actually touches. This does not reduce total work; it changes *when* each part becomes usable, which is often the metric that matters. **Make the critical path degrade gracefully.** Whatever the page is for — search, checkout, sign-in — should be built from elements the browser understands, so it functions during the window when no client code has run at all. This is the only lever that helps before hydration starts. **Keep expensive work out of render.** Anything computed inline in a component body runs on the server and again during hydration. Heavy synchronous work in render is paid twice, and the second time is on the user's device. ## The tradeoffs to weigh out loud None of this is free, and a principal-level answer says so. - **Splitting adds surfaces.** More boundaries mean more loading states to design, more chances for content to shift as regions arrive, and a page whose behaviour is harder to reason about and to test. - **Shrinking the client tree constrains authors.** A rule about what may be interactive is a rule engineers will hit while building features; it needs to be a documented standard with a clear escape hatch, not folklore. - **The last increments cost the most.** Cutting hydration from four seconds to two is usually a handful of structural changes; two to one can consume a quarter and deliver less user-visible benefit than something else on the roadmap. - **Some pages should not carry this model.** If a surface produces almost no meaningful HTML before its data arrives, server rendering plus hydration buys little and costs a full duplicate render. Being willing to say that about a specific page is part of owning the decision. ## Turning it into a standard What I want to leave behind is not a one-off fix. A hydration budget for the page, expressed in terms an engineer can check, plus real-user interaction monitoring with alerting on regressions, plus a short written rule about what belongs in the client tree, keeps the page from silently drifting back over the next twenty features. Otherwise the fix decays in a quarter. ## Interview framing Lead with the cost model, then measurement, then levers, then the price of each lever. The failure mode to avoid is reciting optimisations without a model — that answer cannot explain why memoization does not help, and that question is coming.