SSR
Server-Side Rendering: generating HTML on the server for each request. Slower than SSG but always returns fresh data. Good for personalized or frequently changing pages.
What is SSR?
In short
Server-Side Rendering (SSR) is a technique where a web server generates the full HTML for a page on every request, runs your application code with the current data, and sends finished markup to the browser instead of an empty shell. It trades a bit of server work and per-request latency for fresh, personalized content and HTML that search engines and social crawlers can read immediately.
What SSR actually is
When a browser asks for a page, SSR means the server runs your component code right there, fetches whatever data the page needs, turns it into a complete HTML document, and ships that back. The user sees real content the moment the HTML arrives, before any JavaScript has loaded or run.
Contrast this with two neighbors. Client-Side Rendering (CSR) sends a near-empty HTML file plus a JavaScript bundle, and the browser builds the page after download. Static Site Generation (SSG) builds the HTML once at deploy time and serves the same file to everyone. SSR sits in the middle: HTML is built fresh, but per request, by a running server.
After SSR delivers the HTML, the browser usually still downloads the JavaScript and runs hydration, which attaches event handlers to the already-painted markup so buttons, forms, and navigation become interactive. So the user gets fast first paint from the server and full interactivity once hydration finishes.
How it works under the hood
A request hits the server. The framework matches it to a route, runs that route's data fetching (a database query, an API call, reading the user's session cookie), and then renders the component tree to a string. In React this is renderToString or renderToPipeableStream; the result is HTML plus a serialized snapshot of the data so the client does not have to refetch it.
Modern frameworks stream the HTML in chunks rather than waiting for the whole page. The browser starts painting the header and layout while a slow widget further down is still being computed on the server. React calls this Suspense streaming; Next.js App Router and Remix both lean on it.
Because the server does real work on every request, SSR pages are dynamic by nature. You can read cookies, headers, and geolocation to personalize the output. The cost is that you cannot just drop the response on a CDN forever the way you can with a static file, though you can layer caching like stale-while-revalidate or short TTLs on top.
When to use it and the trade-offs
Reach for SSR when the page content depends on who is asking or changes often: a logged-in dashboard, a shopping cart, search results, a feed, a price that updates by region. It is also the right call when SEO and link previews matter, because crawlers and social scrapers get complete HTML instead of a blank shell they may not execute.
The downside is latency and cost. Every request waits for server compute and data fetching, so Time To First Byte is higher than serving a static file, and your servers scale with traffic instead of being a cheap cached asset. Hydration also ships JavaScript anyway, so you pay for both the server render and the client bundle.
If a page is the same for everyone and rarely changes, SSG or Incremental Static Regeneration is faster and cheaper. If content is purely interactive and behind a login where SEO does not matter, plain CSR can be simpler. A common real pattern is mixing them: static marketing pages, SSR for the authenticated app, and React Server Components to keep the client bundle small.
A concrete example
Imagine an e-commerce product page that shows a price, live stock count, and a Recently viewed section pulled from the visitor's cookie. With SSR, the Next.js server reads the cookie, queries inventory, renders the full page with the correct price and stock, and returns finished HTML. Google indexes the real price and description, and the user sees the product instantly.
The same page built with CSR would arrive blank, then flash in once JavaScript fetched the data, which hurts the largest-contentful-paint metric and risks crawlers seeing nothing. Built with pure SSG, the stock count would be frozen at build time and the personalized section would be impossible without extra client code.
This is why storefronts and content sites that care about both speed and freshness so often choose SSR for the pages that change, while keeping truly static pages static.
Where it is used in production
Next.js
Its App Router and Pages Router both support per-request SSR, with streaming and React Server Components to cut client JavaScript.
Vercel
Runs Next.js SSR on serverless and edge functions, spinning up a function per request to render HTML close to the user.
Airbnb
Pioneered large-scale React SSR for fast first paint and crawlable listing pages, and open-sourced Hypernova to render React on the server.
Netflix
Serves a server-rendered landing and sign-up experience so the marketing pages paint quickly and stay SEO-friendly before the JavaScript app takes over.
Frequently asked questions
- What is the difference between SSR and SSG?
- SSR builds the HTML fresh on the server for every request, so it can show personalized or up-to-the-second data. SSG builds the HTML once at deploy time and serves the same cached file to everyone, which is faster and cheaper but stale until you rebuild.
- Does SSR mean no JavaScript runs in the browser?
- No. The server sends complete HTML for a fast first paint, but the browser still downloads the JavaScript and runs hydration to make the page interactive. SSR speeds up the first view; it does not remove the client bundle.
- Is SSR good for SEO?
- Yes. Search engine crawlers and social link-preview bots receive full HTML with the real content already in it, so they do not depend on executing JavaScript. That makes titles, prices, and copy reliably indexable.
- Is SSR slower than static rendering?
- Time To First Byte is usually higher because the server does data fetching and rendering on each request instead of serving a prebuilt file. You can soften this with caching headers like stale-while-revalidate, streaming, and edge rendering, but a cached static file is still the fastest possible response.
- What is hydration in SSR?
- Hydration is the client-side step where the JavaScript framework attaches event listeners and state to the server-rendered HTML that is already on screen, turning the static markup into a fully interactive app without repainting it.
Learn SSR hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on SSR as part of a larger topic.
See also
Related glossary terms you might want to look up next.
Static Site Generation (SSG)
Pre-rendering pages to static HTML at build time. The fastest possible page loads because there's no server-side computation on each request.
ISR
Incremental Static Regeneration: a Next.js feature that re-generates static pages in the background after a specified time interval, combining SSG speed with fresh data.
Latency
The time delay between sending a request and getting a response. Amazon found every 100ms of extra latency costs 1% in sales.
Content Delivery
The process of distributing and serving content to users from locations geographically close to them for faster load times.
Edge Computing
Running computation at the network edge, close to the user, instead of in a central data center. Reduces latency for real-time applications like IoT and streaming.
HTTP Caching
Browser and proxy caching controlled by HTTP headers like Cache-Control, ETag, and Last-Modified. Eliminates redundant network requests for unchanged resources.