Hydration is the step where a JavaScript framework takes HTML that was rendered on the server or at build time and attaches event handlers and state to it in the browser. The page is visible before hydration finishes, but buttons and menus may not respond until it does. For SEO, hydration matters because it costs main-thread time and because mismatches between server and client output can change what users and crawlers see.
Why hydration exists
Server rendering gives a fast first paint and crawlable HTML, but the HTML alone is static. Frameworks like React, Vue and Svelte need to rebuild their component tree in the browser and connect it to the existing DOM. That reconnection is hydration. Until it completes, the page looks ready but may not respond to input.
Performance cost
Hydration runs JavaScript on the main thread, often in long tasks. That shows up in lab metrics like Total Blocking Time and in the field as poor Interaction to Next Paint, especially on mid-range phones. The more components a page hydrates, the higher the cost, even if most of them never change.
Newer approaches reduce the work: partial or islands hydration (only interactive parts hydrate), progressive or lazy hydration (components hydrate when visible or used), and server components that never ship JavaScript for non-interactive parts.
Hydration mismatches
If the HTML produced in the browser differs from the server HTML, frameworks warn about a mismatch and may re-render the affected section. Common causes are dates, random IDs, user-specific content or browser-only APIs used during render. A mismatch can make content flicker or change after load, which can cause layout shift and, in bad cases, means the server HTML a crawler indexed differs from what users see.
Example
Cutting hydration on a marketing page
A feature page at Brambleport, a customer feedback tool, renders on the server but hydrates the whole page, including long text sections and a footer. Lighthouse shows high Total Blocking Time on mobile. The team converts static sections to server-only components and hydrates only the pricing toggle and demo form. The visible page is unchanged; far less JavaScript runs on load.
Common mistakes
Ignoring hydration warnings in the console
Mismatch warnings point to content that changes after load. Fix them; they can cause layout shift and inconsistent content.
Hydrating content that never changes
Text, images and footers rarely need client-side state. Shipping JavaScript for them adds cost with no benefit.
Questions
Google renders pages in a headless Chromium, so it generally sees the result after scripts run. The server HTML still matters for crawlers that do not render and for indexing signals read from the raw response.
