Progressive Hydration
Progressive hydration delays non-essential interactivity — users should access meaningful content before full enhancement.
01 — Purpose
Enhance in priority order
Progressive hydration delays non-essential interactivity — users should access meaningful content before full enhancement.
Full-page hydration runs JavaScript across every component before the page feels ready. Progressive hydration prioritises what users need first — header, main content, primary actions — and defers the rest until idle time or interaction.
See hydration costs and islands architecture.
02 — Principles
Content before full interactivity
Hydration should support usability progressively.
- prioritise critical UI — navigation, main task, above-the-fold controls
- delay secondary interaction — carousels, comments, analytics widgets
- reduce hydration pressure — fewer components on the main thread at once
03 — Practice
Good progressive hydration
Improved responsiveness and lower JS execution cost.
- ship static HTML for read-only content — hydrate only interactive islands
- hydrate on visible — use intersection or user intent before loading component JS
- split by route and feature — dynamic import for tabs, modals, and secondary panels
- use idle callbacks where appropriate — defer non-critical enhancement after first paint
- measure INP before and after — see Core Web Vitals
04 — Avoid
Hydration bottlenecks
Blocking interaction unnecessarily defeats the purpose of progressive enhancement.
- hydration bottlenecks — one large bundle blocking all interactivity
- blocking interaction unnecessarily — primary button waits on footer widget hydration
- hydrating below-the-fold before LCP — wasted main-thread work
- progressive hydration without fallbacks — static HTML must work without JS
- over-splitting — too many tiny chunks with request overhead; see JavaScript cost
05 — Close
Hydrate what earns it
Users should read and act on core content before optional widgets wake up.
Map interactivity to user priority. Hydrate the checkout button before the recommendation carousel. Verify with throttled CPU that first interaction remains fast.
See islands architecture, static vs SSR vs CSR, and JS module architecture.