Hydration Costs
Hydration reconnects JavaScript to HTML — it is not free, and users feel every delay.
01 — Purpose
Hydration is not free
Hydration reconnects JavaScript behaviour to server-rendered HTML — users wait for it 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.
See JavaScript standard and JavaScript cost for keeping client work minimal.
02 — Principles
Interaction should not wait unnecessarily
Hydration should improve interaction — not delay it.
- ship HTML that works without JavaScript first — enhance, do not replace
- hydrate only what needs client behaviour — not every static paragraph
- measure INP and Time to Interactive on real pages — not only bundle size
03 — Practice
Reduce hydration cost
Islands, selective hydration, and less client rendering.
- islands architecture — small interactive archipelagos in static seas
- defer hydration for below-the-fold widgets until visible or idle
- prefer server or static HTML for content-heavy pages — this site uses Astro with minimal client JS per page
- avoid hydration waterfalls — parallelise and split by route or component
- question every client component: could native HTML or CSS do this?
04 — Problems
Common hydration pain
Delayed interaction and duplicated work show up in reviews and field data.
- entire page hydrates before any button responds
- client-only rendering of content that could be static HTML
- serial async imports blocking hydration start
- layout shift when client components replace server markup differently
05 — Close
Default to static
The cheapest hydration is none at all.
For marketing, docs, and reference content, static HTML with targeted script modules often beats a fully hydrated app shell. Reach for frameworks when interaction complexity demands it — not by default.
Related: Core Web Vitals, JS module architecture.