hydration

Hydration exists because server-side rendering (SSR) and static generation (SSG) create a split. The server ships finished HTML so browsers and crawlers get content immediately, but that markup is inert: no click handlers, no state. Hydration is the second pass where the framework re-runs the same component tree in the browser, walks the existing DOM, and wires up event listeners instead of rebuilding nodes. In React this is triggered by hydrateRoot rather than createRoot. The terms hydration and rehydration are used interchangeably; Google’s docs even write it as “(re)hydration.”

The mismatch trap

The client render has to produce the same output the server did. React’s docs are explicit: the tree you pass to hydrateRoot “needs to produce the same output as it did on the server,” and you should “treat mismatches as bugs and fix them.” Common causes of a mismatch are branching on typeof window, rendering timestamps or random values, or reading window.matchMedia during render. When output diverges, React logs a hydration error and can fall back to a full client render, clearing the server-rendered HTML it was supposed to reuse. That means a blank flash and lost content for anything that depended on the first paint.

The bigger cost is timing. Google describes an “uncanny valley” where a page looks loaded but ignores taps until the JavaScript downloads, parses, and finishes attaching handlers. On mobile that gap can run long, and it lands directly on Total Blocking Time and Interaction to Next Paint (INP). Google’s own measurement is blunt: real-world data on SSR with rehydration “indicate that it’s rarely the best option,” mostly because a page can look ready while none of its interactive features work.