Hydration and Why It's Expensive

Server-rendered HTML solves the "blank screen while JS loads" problem — the browser has real content to paint the moment the response arrives. But that HTML is inert. It has no event listeners, no component state, no reactivity; it's a picture of what the app should look like, not the app itself. Getting from that picture to a working, interactive application is hydration's job, and it is not free.

What hydration actually does

Hydration re-runs your component tree in the browser, against the DOM nodes that already exist, attaching everything a framework needs to make them interactive: event handlers, internal state, the reconciliation bookkeeping it uses to know what changed later. Critically, this is a second, real execution of your rendering code — the framework isn't just "turning on" the existing markup, it's rebuilding its internal model of the page and matching it against what's already on screen.

1. Step 1

   Server renders HTML

   Your component tree executes on the server and produces real, paintable markup.

2. Step 2

   Browser receives and paints it

   The user sees a complete-looking page — but nothing responds to clicks or typing yet.

3. Step 3

   JS bundle downloads, parses, executes

   This is pure overhead time from the user's perspective: the page looks done but isn't.

4. Step 4

   Hydration runs

   The same component tree re-executes in the browser, attaching event listeners and state to the existing DOM nodes.

5. Step 5

   The page becomes genuinely interactive

   Only now do clicks, typing and re-renders actually work.

Why this is a genuinely expensive step

Three costs stack on top of each other, and all three scale with your JS bundle size and the device's CPU: download (the bundle has to arrive before anything else can happen), parse and compile (the JS engine has to turn that bundle into executable code before running a line of it), and execution (hydration itself walks the tree and does real work). On a high-end laptop this whole sequence can be imperceptible. On a mid-range phone with a large bundle, it can take seconds — and during that window, a page that looks completely done silently ignores every tap, which is a worse user experience than an honest loading spinner, because there's no visible signal that anything is still happening.

Reducing the cost, without giving up SSR

Partial (or selective) hydration starts from the observation that most pages are mostly static content wrapped around a few genuinely interactive widgets. Instead of hydrating the entire tree, only the components that actually need client-side behavior — a carousel, a form, a "like" button — ship JS and get hydrated; everything else stays exactly as the server sent it, forever inert in the useful sense (never needing to be), because it never needed interactivity in the first place.

Progressive hydration hydrates in priority order rather than all at once — above-the-fold interactive elements first, everything else as the browser has idle time or as each section scrolls into view — so the parts a user is most likely to touch first become responsive soonest, instead of every component competing for the main thread simultaneously.

Resumability (covered next) is a more radical answer: skip re-running component logic in the browser at all, by having the server serialize enough information about what already happened that the browser can attach listeners without ever replaying the render.

What to remember

• Server-rendered HTML is real, paintable markup, but it has no attached behavior until hydration runs the component tree again in the browser.
• Hydration cost is downloading, parsing and executing JS, then re-walking the tree — all of it scales with bundle size and device power, and none of it is visible in how fast the page looked on first paint.
• A page can look done and still not respond to input — that gap is the practical, user-facing cost of hydration.
• Partial and progressive hydration reduce the cost by only hydrating what genuinely needs interactivity, and by prioritizing what hydrates first.