Hydration is the process by which a JavaScript framework takes a static, server-rendered HTML page and makes it fully interactive by attaching event listeners and restoring application state on the client side. The term describes the moment a page transitions from a passive document into a live, dynamic application without requiring the browser to re-render the page from scratch.
To understand hydration, it helps to first understand how server-side rendering (SSR) works. When a user requests a page, the server generates a complete HTML document and sends it to the browser. The browser can display this HTML immediately, which is why SSR improves perceived load times and is beneficial for search engine crawlers. However, that initial HTML is inert: buttons do not respond to clicks, forms do not validate input, and no JavaScript-driven interactivity exists yet. Hydration is the subsequent step that resolves this limitation.
Once the browser has rendered the HTML, the JavaScript bundle for the framework - such as Next.js, Nuxt, or SvelteKit - is downloaded and executed. The framework then traverses the existing DOM, matches its internal component tree against the server-rendered markup, and binds the necessary event handlers and reactive logic in place. This reconciliation process relies on the Virtual DOM in frameworks like React, which compares the expected structure against what is already on screen. If the server-rendered HTML matches what the client-side framework would have produced, hydration proceeds efficiently. If there is a mismatch - often called a hydration error - the framework may be forced to discard and re-render portions of the page, which can cause a visible flash or layout shift.
Hydration is closely related to Static Site Generation (SSG), where HTML is pre-built at compile time rather than generated on each request. In both SSR and SSG scenarios, the HTML arrives at the browser before JavaScript runs, and hydration is what bridges the gap between a static document and an interactive application.
Because hydration requires the full JavaScript bundle to be downloaded, parsed, and executed before interactivity is available, it introduces a window of time where a page looks ready but does not yet respond to user input. This gap is measured by metrics such as Time to Interactive (TTI) and is a known performance consideration for teams building with SSR frameworks. Modern approaches such as partial hydration and progressive hydration address this by hydrating only the components that require interactivity, deferring or skipping hydration entirely for static portions of the page. Some newer frameworks, such as Astro, take this further with an architecture sometimes called islands architecture, where interactive components are hydrated independently from the surrounding static content.
For developers and SEO professionals alike, understanding hydration is important because it explains why a page can appear fully rendered in a browser or crawler screenshot yet still lack functionality, and why JavaScript execution timing matters for both user experience and Core Web Vitals scores.