Skip to main content

SSR

Server-Side Rendering

Updated 2 min read

Share this page

Send the link, quote the definition with a link back, or show it as a card on your own site.

https://softwaredictionary.org/terms/ssr

In short

SSR is a technique where the server builds the full HTML for a page on each request, so users and search engines receive ready-to-read content immediately.

What is SSR?

With server-side rendering, the server runs the application code, fetches any data it needs, and produces complete HTML before sending the response. The browser can display that content right away instead of waiting for JavaScript to download and build the page itself.

In modern JavaScript frameworks, SSR is usually followed by hydration: the browser downloads the JavaScript, attaches event handlers to the existing HTML, and the page becomes fully interactive. Frameworks such as Next.js, Nuxt, and SvelteKit support this model, and techniques like streaming send parts of the page as soon as they are ready.

A restaurant analogy helps: client-side rendering hands you raw ingredients and a recipe to cook at your table, while SSR serves the finished dish. You can eat sooner, and anyone glancing at the table, including search engine and AI crawlers, can see what the meal is.

SSR is often confused with static site generation (SSG). SSR renders HTML on every request, which suits personalized or frequently changing pages, while SSG renders pages once at build time and serves the same files to everyone, which is faster and cheaper but less dynamic. Many sites mix SSR, SSG, and client-side rendering (CSR) page by page.

At a glance

The same page rendered two ways. With SSR the server sends finished HTML, so the content shows as soon as it arrives and becomes interactive once the JavaScript has hydrated it. With client-side rendering the browser first gets an empty page and shows content only after downloading JavaScript and fetching the data.SSRserver rendersJavaScript loadshydratecontent visibleClient-sideemptyJavaScript loadsfetch datarendercontent visibletime
SSR puts the content on screen sooner, which helps slow devices and search engines. SSG does the same rendering once, at build time.

Key takeaways

  • SSR generates HTML on the server for each request.
  • Users see content sooner, especially on slow devices.
  • Crawlers receive complete content, which helps SEO.
  • Hydration makes server-rendered HTML interactive in the browser.
  • SSG renders at build time; SSR renders at request time.

Example

Rendering HTML on the server with Node.jsjavascript
import { createServer } from "node:http";

createServer(async (req, res) => {
  // Fetch data on the server, before responding
  // (getLatestPosts and escapeHtml are helpers defined elsewhere)
  const posts = await getLatestPosts();
  const items = posts.map((p) => `<li>${escapeHtml(p.title)}</li>`).join("");

  // Send complete HTML that the browser can display immediately
  res.setHeader("Content-Type", "text/html; charset=utf-8");
  res.end(`<h1>Latest posts</h1><ul>${items}</ul>`);
}).listen(3000);

Readers ask

What is the difference between SSR and SSG?

SSR builds a page's HTML on the server each time it is requested, while SSG builds it once at build time and reuses the same file for every visitor. SSG is faster to serve; SSR is better for content that changes often or depends on the user.

What is the difference between SSR and CSR?

With client-side rendering (CSR), the server sends a mostly empty page and JavaScript builds the content in the browser. With SSR, the server sends finished HTML, so content appears sooner and is easier for crawlers to read.

What is hydration?

Hydration is the step where JavaScript running in the browser takes over server-rendered HTML, attaching event handlers and state so the page becomes interactive.

Often compared

See also

Spotted a mistake or something missing on this page?Suggest an edit

Read a random page
Open today's review
Switch to the dark theme
Read this page in Türkçe

More

Settings