We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Web & Content Delivery
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.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers SSR across a run of lessons, not one page. These 4 alone are about 71 minutes of step-by-step reading, every one with a quiz.
Generating HTML on the server for each request, fast first paint, SEO-friendly, and dynamic content.
Updating static pages after build time without rebuilding the entire site, the best of SSG and SSR combined.
Rendering pages entirely in the browser with JavaScript, how SPAs work and when they make sense.
Distributed search engines that power product search, log analysis, and real-time analytics at massive scale.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Server-Side Rendering (SSR)pay once,
yours for life
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This page explains the idea. The "Server-Side Rendering (SSR)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Server-Side Rendering (SSR) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about SSR in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
