Selective hydration
Slap yourself if
You think hydration is a single on/off switch that just needs to be faster.
Why this exists
Selective hydration exists because full, eager hydration blocks interactivity on the main thread. Most of the UI does not need to be interactive immediately, but traditional hydration treats it as if it does.
Mental model
Hydration is attaching behavior to already-rendered markup. Selective hydration decides which parts earn interactivity now, which can wait, and which might never need it.
- Server-rendered HTML is painted without JavaScript execution.
- Hydration work is scheduled to bind event handlers and state.
- Only prioritized subtrees are hydrated immediately.
- Other parts remain inert until triggered or idle time appears.
- Assuming unhydrated UI is equivalent to static HTML.
- Unexpected delays when interacting with deferred regions.
- Hydration order depending on user interaction timing.
- State mismatches between server and late-hydrated components.
Selective hydration is a strategy where only specific parts of a server-rendered UI are hydrated immediately, while others defer attaching interactivity to reduce blocking and improve perceived performance.
- Hydrating the entire tree by default
- Critical interactions hidden behind deferred hydration
- Assuming hydration cost is negligible
- Ignoring event replay or buffering semantics
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.