Server rendering gets readable content on screen quickly. Hydration is what happens next: the framework downloads, re-runs the component tree, matches it against the existing markup and attaches the event handlers. Until that finishes, the page looks ready and is not — buttons are visible and do nothing, which is a worse experience than an honest spinner.
Two failure modes are worth knowing. A mismatch, where the server and the client disagree about what should be there, produces a console error and a re-render — anything that depends on the current time, a random value or the window will do it. And an over-hydrated page ships interactivity for components that never needed it, which is why the useful question is which parts of a page actually have to be alive.
Related terms
Static generation (SSG)
Rendering pages to HTML at build time, so a request is answered by handing over a file instead of running code.
Core Web Vitals
Google's three field metrics for loading, responsiveness and visual stability, measured on real visits rather than in a lab.
LCP (Largest Contentful Paint)
The moment the biggest piece of content in the viewport finishes rendering — in practice, when the page looks loaded.
The bench this belongs to
Full-stackIf you can describe it, we can build it. React and Next.js on the front, Python or Node behind, Postgres underneath, shipped to somewhere you can afford to run.
