SSRServer-Side Rendering
Generating the HTML for a page on the server for each request, then sending it fully formed to the browser before hydration takes over.
· Reviewed by senior engineers
Server-Side Rendering (SSR) is the practice of generating a page's HTML on the server for every request, then sending it to the browser fully formed. The user sees content immediately, search engines crawl real HTML, and the JavaScript bundle then hydrates the page to make it interactive. Next.js, Remix, Nuxt and SvelteKit all support SSR as a first-class mode.
SSR is the right default for any page whose content depends on the request — the logged-in user, geo-location, A/B test bucket, or freshly-changing data like stock levels. It gives you the SEO and first-paint benefits of static HTML without the staleness of a pre-built page.
The cost is server compute. Every request runs your render code, hits your data sources and produces HTML. At scale that means caching layers (CDN, Redis, in-memory) and careful database access. SSR also makes deployments more sensitive — a slow database query that was fine in a SPA now blocks the entire page.
We pick SSR when content is dynamic or personalised, switch to SSG or ISR when it isn't, and combine the two on the same site without hesitation. Next.js makes the boundary a per-route decision, which is how it should be.