Partial Hydration
Partial hydration is a rendering strategy in which only specific interactive portions of a server-rendered page are hydrated with JavaScript on the client, while the rest of the page remains static HTML. It reduces the amount of JavaScript…
Definition
Partial hydration is a rendering strategy in which only specific interactive portions of a server-rendered page are hydrated with JavaScript on the client, while the rest of the page remains static HTML. It reduces the amount of JavaScript shipped and executed compared to hydrating an entire page.
Overview
Traditional server-side rendering in frameworks like early React or Vue renders full HTML on the server for fast first paint, but then 're-hydrates' the entire page on the client by re-running the same component tree in the browser to attach event listeners and restore interactivity. This full-page hydration is expensive: even mostly static content (headers, footers, article text) gets bundled, parsed, and hydrated as if it were interactive, which slows down time-to-interactive, especially on lower-powered devices. Partial hydration addresses this by hydrating only the components that actually need interactivity — a carousel, a comment form, a like button — while leaving the surrounding static markup as plain HTML that never receives a JavaScript event listener or virtual DOM tree. This dramatically cuts the JavaScript bundle size sent to the client and the CPU work spent on hydration, since inert content is skipped entirely rather than hydrated and then effectively doing nothing. The technique is most closely associated with the Islands Architecture pattern, pioneered in frameworks like Astro, Marko, and (earlier) Preact-based approaches, where each interactive component is an independent 'island' hydrated on its own schedule and trigger — for example, hydrating only when the island scrolls into view, when the browser is idle, or immediately on load, depending on its declared priority. Partial hydration is distinct from but often paired with 'resumability,' a related but different approach used by frameworks like Qwik, which avoids traditional hydration altogether by serializing application state into the HTML and resuming execution lazily on interaction rather than re-executing component code upfront. Partial hydration matters because it directly targets one of the biggest performance costs in modern JavaScript-framework-rendered sites: unnecessary client-side re-execution of code whose only job was to have already produced static markup.
Key Concepts
- Hydrates only interactive components, leaving static markup untouched
- Reduces JavaScript bundle size and parse/execution time on the client
- Often implemented via per-component hydration directives (e.g., on load, on visible, on idle)
- Core mechanism behind the Islands Architecture pattern
- Improves Time to Interactive and Total Blocking Time performance metrics
- Distinct from, but complementary to, resumability approaches like Qwik's
- Supported natively in frameworks such as Astro, Marko, and Fresh
Use Cases
Frequently Asked Questions
From the Blog
TypeScript Utility Types You Should Know
TypeScript utility types like Partial, Pick, Omit, and Record transform existing types without rewriting them. Here are the ones you will reach for daily.
Read More Projects & Case StudiesWeb Portfolio Projects: Picking Ones With Real Constraints
A portfolio project teaches you something only when it contains a constraint you cannot avoid — concurrency, time zones, money, authorisation or partial failure. This guide explains which constraints are worth choosing, how to scope a project around one, and what turns a demo into something that reads as production work.
Read More ProgrammingNext.js App Router Explained: Routing, Rendering, Data
The App Router works on one rule: everything is a server component until you opt out, and the file system defines both the URL and the UI nesting. Learn how routes, layouts, server and client boundaries, data fetching and the caching layers fit together, so rendering and hydration behaviour stops being surprising.
Read More Data ScienceHow to write a retention cohort query in SQL that survives review
Build a retention cohort in four layers: first event per user, a period index from date arithmetic, active-period facts, then the cohort-by-period grid. Most broken cohort charts come from partial trailing periods read as decline, time-zone boundaries misassigning users, and cohort dates recomputed on every run.
Read More