Hydration and Client Interactivity

Last updated:

Hydration reconnects JavaScript to HTML — islands and progressive hydration reduce what users wait for.

01 — Purpose

Hydration is not free

Hydration reconnects JavaScript to server-rendered HTML — users wait for that work before the UI feels fully interactive.

Frameworks that render HTML on the server then hydrate on the client pay twice: generate markup, then attach listeners and state. That second pass costs download, parse, execution, and often delays input responsiveness — especially on mid-range phones.

See JavaScript cost and progressive enhancement strategy.

02 — Cost

What hydration costs you

Ship HTML that works first — hydrate only what needs client behaviour.

  • entire page hydrates before any button responds
  • layout shift when client markup disagrees with server HTML
  • measure INP and Time to Interactive — not only bundle size

03 — Islands

Hydrate only interactive regions

Islands architecture keeps static HTML static — small interactive archipelagos instead of a full-page client app.

  • static or SSR shell for content — Astro-style minimal client JS per route
  • isolate widgets that truly need state — not every paragraph
  • avoid hydration waterfalls — parallelise and split by route or component

04 — Progressive

Defer non-critical hydration

Progressive hydration delays below-the-fold or secondary widgets until visible or idle.

  • prioritise critical UI — header nav, primary form, main CTA
  • defer carousels, comments, and related products until needed
  • question every client component: could native HTML or CSS do this?

05 — Close

The cheapest hydration is none

Default to static HTML with targeted script modules for content-heavy pages.

Reach for full client hydration when interaction complexity demands it — not because the framework default did.

See rendering strategy, Core Web Vitals, and JS module architecture.

Common questions

What is hydration cost on the frontend?

Hydration is the work to attach client JavaScript to server-rendered HTML so components become interactive. It delays interactivity and can cause layout shift if markup and state disagree.

How do you reduce hydration cost?

Ship less JavaScript, hydrate only what needs interactivity, use islands or progressive enhancement, and avoid hydrating decorative or static regions.

Is server rendering enough for performance?

SSR improves first paint, but users still pay for download, parse, and hydration. Measure Total Blocking Time and Interaction to Next Paint, not HTML alone.