Imagine you’re on a slow mobile network, scrolling through the news on your phone. The page loads instantly — text, images, layout all appear right away. Visually, it seems ready. You tap “Read more.”
Nothing happens.
A second tap. Still nothing. Then suddenly the page springs to life and behaves normally.
What you just experienced is the hidden cost of hydration — the process modern frameworks use to “wake up” server-rendered HTML in the browser. It’s clever, it has served us well, but it’s far from lightweight.
This article explores why hydration is computationally expensive and how partial hydration offers a more efficient path forward.
Understanding Hydration
Server-side rendering (SSR) allows users to see the interface immediately by delivering HTML first. However, HTML on its own is static — it cannot handle clicks, form inputs, or interactive components.
Hydration is the browser’s process of:
- Downloading the JavaScript bundle
- Parsing and executing it
- Rebuilding the UI tree in memory
- Matching it to the existing DOM
- Attaching event listeners and restoring state
In simple terms, the browser receives a fully-rendered page, but then re-renders the application internally to attach behavior. The UI looks complete, but it’s not truly functional until hydration finishes.
Why Hydration Is Expensive
Hydration introduces performance overhead because the browser ends up doing more work than necessary. It renders the UI twice — first on the server for visual output, then again on the client to attach interactivity — and that cost becomes noticeable as applications scale.
1. Large JavaScript Bundles
Even though the HTML arrives fully rendered, hydration still requires sending down the entire JavaScript bundle responsible for building the UI.
This includes framework code, component logic, routing, state management, and event handlers — essentially the same resources a client-side SPA would load.
So instead of “SSR saves work,” you're shipping HTML and a full client runtime.
More JavaScript means:
- Higher network transfer impact (especially on slow or unstable networks)
- Longer download and decompression time
- More memory usage right after page load
SSR gets pixels on the screen faster, yes — but hydration delays when those pixels become useful.
2. Heavy CPU Work
Once downloaded, the browser must parse, compile, and execute the JavaScript — and that’s where the CPU load hits.
Parsing and executing JavaScript isn't free. It blocks the main thread, the same thread responsible for:
- Animations
- Scrolling
- Input responsiveness
- Layout and paint operations
On modern laptops, this cost may feel small. On mid-range Android phones or older devices, it's painful. A page that looks ready turns sluggish simply because JavaScript hasn’t finished bootstrapping yet.
3. Duplicate Rendering Work
SSR gives the browser a complete DOM tree. But hydration doesn’t reuse that DOM directly.
The framework rebuilds its virtual component tree in JavaScript, reconciles it, and then attaches behaviors to the existing DOM nodes.
It’s like assembling the same puzzle twice — once on the server and once inside the user's device — just to verify the pieces fit.
That duplicated effort wastes:
- CPU cycles
- Memory
- Startup time
The UI is already there — the browser just has to re-understand it.
4. Hydrating Everything, Even Static Content
Traditional hydration approaches treat every part of the page as potentially interactive. The framework walks through the entire DOM — even sections that will never change or respond to input.
Static blocks like:
- Article text
- Footer content
- Product descriptions
- Banner images
all get swept into the hydration process simply because they live inside a component tree.
This is equivalent to activating every circuit in a building even if most rooms won’t be used.
Most pages don’t need to hydrate 100% of their UI, yet traditional hydration does exactly that.
5. Delayed Interactivity and Perceived Lag
Until hydration completes, the interface is visually present but functionally incomplete. Buttons exist, but they may not respond. Input fields appear ready, but keystrokes don’t register immediately.
This gap between first paint and usable interface damages user trust.
Developers see it as a “hydration window.”
Users see it as:
- “The site is slow”
- “This button doesn’t work”
- “Is my phone freezing?”
- “Why hasn’t the menu opened yet?”
It affects core metrics like Time to Interactive (TTI) and Interaction to Next Paint (INP), and ultimately shapes how users perceive your product.
The Bottom Line
Hydration solves an important problem — fast HTML rendering with rich interactivity — but it does so by making the browser redo work it already received from the server.
The result: pages that arrive fast, but become usable slowly.
Partial hydration and modern approaches aim to cut out this redundancy, enabling only the parts that truly need JavaScript to hydrate — and only when necessary.
Partial Hydration: A More Targeted Approach
Partial hydration addresses this problem by only hydrating components that truly need interactivity.
Instead of rehydrating the entire page, the browser focuses on smaller, isolated “islands” of interactive functionality — like navigation menus, search bars, or carousels — while leaving static content untouched.
Benefits include:
- Less JavaScript sent to the browser
- Reduced CPU usage and faster processing
- Faster time-to-interactive (TTI)
- Better performance on low-end devices
- A more efficient rendering pipeline overall
In other words, the browser hydrates only where necessary, rather than everywhere by default.
Real-World Adoption
Many modern frameworks are embracing this model:
- Astro: Islands architecture, zero-JS by default
- Qwik: Resumability — skips hydration entirely
- SvelteKit: Compiles away much runtime overhead
- Next.js (App Router): Server components reduce hydration scope
- Solid: Extremely fine-grained, selective hydration
The trend is clear: ship less JavaScript, hydrate less, and push more execution back to the server.
The Shift in Frontend Thinking
For years, the industry moved toward increasingly complex client-side JavaScript. We treated the browser as the primary execution environment.
That tide is turning.
The new direction emphasizes:
- Minimal client-side JavaScript
- Server-driven interfaces
- Progressive enhancement
- Distributed and selective interactivity
The goal isn’t to remove interactivity — it’s to be strategic about where it’s needed.
Conclusion
Hydration was an essential stepping stone in modern web architecture. It allowed us to combine server-rendered speed with client-side richness. But as applications grow and devices vary widely in capability, we can no longer afford to hydrate everything by default.
Partial hydration — and the evolution beyond it — reflects a smarter, more efficient approach:
Deliver the UI quickly.
Hydrate only what the user interacts with.
Avoid unnecessary work in the browser.
It’s a shift toward performance, practicality, and user-first engineering — a cleaner and more sustainable direction for the future of frontend development.
Top comments (0)