Hydration Performance

The plain-language idea

You already know what hydration is at a mechanical level: attaching event listeners and reactivity to server-rendered HTML that's already sitting in the DOM. What matters here is the performance gap that process opens up. The page is painted — a user can see it, read it, and reasonably assume it works — before it's interactive, because hydration hasn't finished running yet. If a user clicks a button in that gap, nothing happens, or the click is queued and handled late. That's a real, measurable cost, and it shows up directly in INP: a click that lands during hydration has to wait for hydration's JS to finish before the browser can even begin processing it.

The size of that gap scales with how much JavaScript has to run before the page is considered "hydrated." A small, simple page hydrates in a few milliseconds and the gap is invisible. A large page with a lot of components hydrating all at once can leave a user staring at a page that looks done but isn't, for a genuinely noticeable stretch.

See it in a real thing: the spectrum of how much hydrates, and when

Every mitigation pattern here is really the same idea, applied more or less aggressively: instead of hydrating the entire page in one pass the moment JS is ready, hydrate only what actually needs to be interactive, prioritized by what the user needs first.

• Partial (selective) hydration — the page ships with some components marked as needing hydration and others (purely static content, like an article body or a footer) never hydrated at all. Only the parts that are actually interactive pay hydration's JS cost.
• Progressive hydration — components hydrate in priority order as the main thread has capacity, often tied to visibility (a component below the fold defers its hydration until it scrolls into view, instead of competing for main-thread time the moment the page loads).
• Islands architecture — the most aggressive point on the same spectrum. Most of the page ships as plain static HTML with zero JavaScript at all; only specific, deliberately-marked interactive "islands" (a like button, a comment form, a carousel) hydrate, each independently, and everything between them stays inert markup forever.

What people usually miss

Watch out

• A painted page is not the same claim as an interactive page. It's easy to eyeball a fast-looking page and assume it's fast everywhere; the hydration gap is invisible unless you specifically measure interaction responsiveness, not just paint timing.
• More components hydrating at once means more main-thread contention, not just more total work. Hydrating fifty components in one synchronous pass doesn't just take longer in aggregate — it also means any single one of them can be mid-hydration, blocking the thread, exactly when a click comes in.
• These patterns trade upfront complexity for a real, measurable INP improvement, not a free win. Deciding what's "static enough" to skip hydration, or which components deserve priority, is a real design decision — the earlier hydration mismatch lesson's rule (client output must match server output for whatever does hydrate) still applies to every hydrated piece.
• Hydrating less isn't the same as shipping less HTML. Islands architecture still sends full static markup for the non-interactive parts — the savings are in JavaScript execution and parse/compile cost, not in the size of the HTML response itself.

Why this matters in interviews

"The page looks loaded instantly but feels janky for the first second or two when a user interacts with it — why, and what would you do about it?" is a real senior-level question, and naming the hydration gap's effect on INP, plus a concrete mitigation like selective hydration or islands, is a much stronger answer than assuming the page is simply "slow."