Partial Hydration

Slap yourself if

You think partial hydration just means hydrating components later.

Why this exists

Partial hydration exists to reduce the cost of hydrating large server-rendered pages by only hydrating interactive or visible parts, instead of eagerly hydrating the entire DOM tree.

Mental model

Partial hydration treats hydration as a selective process. Only parts of the server-rendered UI that require interactivity are hydrated, while the rest remains static HTML until needed.

  • The server sends fully rendered HTML to the browser.
  • The browser paints static content immediately.
  • JavaScript is loaded, but hydration is deferred for non-interactive regions.
  • Interactive islands or boundaries are hydrated on demand.
  • Non-hydrated regions remain inert until explicitly activated.
  • Assuming non-hydrated content can handle events.
  • Hydrating too many small islands and increasing overhead.
  • Breaking shared state assumptions across hydrated and non-hydrated regions.
  • Unexpected delays when user interaction triggers hydration.

Partial hydration is a strategy where only selected parts of a server-rendered page are hydrated on the client, reducing initial JavaScript work while preserving interactivity where needed.

  • Partial hydration is just lazy loading.
  • Everything eventually hydrates anyway so it doesn’t matter.
  • It always improves performance.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

How partial hydration actually works

Partial hydration is not a React feature alone — it is a coordination problem between framework, runtime, and compiler.

How partial hydration can backfire

Partial hydration reduces work — until it increases it.

Tradeoffs vs full and selective hydration

Partial hydration optimizes for startup cost, not total complexity.

Interview landmines

  • Confusing partial hydration with lazy loading.
  • Claiming it eliminates hydration cost entirely.

Related terms