Hydration cost: selective, progressive, islands, resumability

A news article page: 2,000 words of text, one comment box, a like button. Classic full-page hydration runs the framework across all 2,000 words of text — making text that has no interactivity “interactive.” The bundle is larger than it needs to be and the hydration long task blocks the main thread, spiking INP. There are better options.

Why hydration is expensive. Hydration roughly doubles render work — the tree is rendered once on the server and effectively rendered again on the client. But it is worse than a simple doubling, because the client render runs on the user’s device, which may be a mid-range phone an order of magnitude slower than your server. And it is all main-thread JavaScript: downloading the bundle, parsing and compiling it (V8 work), then running the component tree and attaching handlers. On a large app this is hundreds of milliseconds to seconds of main-thread time during which the page looks done but is not. This whole window is the “uncanny valley” of SSR — the page is painted and looks interactive, the user tries to interact, and the input is dropped or queued behind the hydration long task, spiking INP.

Full vs selective hydration. Classic React hydration is full and eager: the whole app hydrates in one pass before anything is interactive, and it is blocking. React 18 introduced selective hydration: with Suspense boundaries, parts of the tree hydrate independently, and React prioritises hydrating whatever the user just interacted with. If the user clicks a not-yet-hydrated section, React hydrates that section first, ahead of the rest. It also makes hydration interruptible — it can yield to input mid-hydration. Selective hydration does not remove the total cost; it reorders it so the cost lands where the user is not looking and the part they touched comes alive first.

Progressive hydration and the islands architecture. The deeper fix is to hydrate less. The islands architecture (Astro, Marko, Fresh) starts from the opposite default: the page is static HTML, and only the specific interactive components — the “islands” — ship JavaScript and hydrate. A blog post is 95% text: with islands, that 95% ships zero JavaScript and never hydrates, and only the comment box and the like button — the actual islands — carry JS. Each island hydrates independently, and can be told when to (client:visible hydrates on scroll into view, client:idle when the main thread is free). This is progressive hydration: the page is interactive where it needs to be, inert and free everywhere else.

Resumability: skipping hydration entirely. Qwik pushes the idea to its limit with resumability. Instead of re-running the component tree on the client to rebuild state and handlers, Qwik serializes the entire application state — including which handler is attached where — into the HTML itself. The client does not re-render to hydrate; it resumes from the serialized state, attaching a handler only when the user actually interacts with that specific element. Startup JavaScript approaches zero regardless of app size. The trade-off is a more complex serialization format and a framework built around it from the ground up — but conceptually it is the endpoint of the whole progression: from “hydrate everything” to “hydrate what the user touched” to “do not hydrate at all, just resume.”