Server-Side Rendering (SSR): Definition, Pros, When to Use

What is server-side rendering (SSR)?

Server-side rendering (SSR) means the server builds a page's HTML when a request arrives and sends it to the browser ready to display. The browser can paint content straight away, then JavaScript loads and makes the page interactive. With client-side rendering (CSR), the server sends a nearly empty shell and the browser builds the page with JavaScript instead.

Frameworks such as Next.js, Nuxt, SvelteKit and Remix support SSR, and most let you choose the rendering mode per route. SSR suits pages whose content depends on the request: search results, logged-in views, live inventory, pages that must be indexable.

How SSR works

1. The browser requests /products/42.
2. The server fetches the data, runs the component tree and generates the HTML.
3. The server sends the HTML and the browser displays it right away.
4. The browser downloads the JavaScript bundle.
5. The script hydrates the page: it attaches event handlers to the existing HTML, and the page becomes interactive.

Between steps 3 and 5 the page is visible but may not respond to clicks yet.

SSR compared with other rendering strategies

SSR can also run at the edge, close to the user, which cuts network latency but limits what code can run there.

A minimal example

Without any framework, SSR is a function that returns a string of HTML. This Express route renders a React component on the server:

import { renderToString } from 'react-dom/server';
import App from './App';

app.get('/', (req, res) => {
  const html = renderToString(<App />);
  res.send(`<!DOCTYPE html>
<html>
  <body>
    <div id="root">${html}</div>
    <script src="/client.js"></script>
  </body>
</html>`);
});

The browser would then load client.js, which calls hydrateRoot to attach to the markup. Frameworks automate this wiring, plus routing, data loading and code splitting.

When SSR is a good fit

• Personalised pages. The HTML depends on who is asking.
• Frequently changing data. Prices, stock levels, news.
• Indexable pages with dynamic data. Product and search pages that crawlers must read as HTML.
• Region-specific content. Currency, language or legal text chosen per request.

When another approach is better

• Marketing and documentation pages. SSG served from a CDN is faster and cheaper.
• Logged-in dashboards with no SEO need. CSR is simpler to host.
• Mixed sites. Static landing pages, SSR for the catalogue, CSR for the app.

The cost of hydration

Hydration is the price of SSR. The browser downloads and runs the same components again to attach behaviour. According to web.dev's guide to rendering on the web, it can hurt Total Blocking Time and Interaction to Next Paint even when it improves First Contentful Paint, so a page can look ready before it responds. Streaming SSR (sending HTML in chunks), React Server Components and island architectures such as Astro all try to reduce how much JavaScript has to run.

Common SSR mistakes

• Using browser APIs on the server. window is not defined is the classic crash.
• Server and client output that differ. A timestamp or random ID makes hydration fail or warn.
• Slow data fetching inside the render. The browser gets nothing until the slowest query finishes.
• No caching. Every request recomputes the page. Cache what is not user-specific and mark personal pages Cache-Control: private.
• Memory leaks. A render server runs for days, so a small leak per request adds up.
• Heavy work in auth middleware. It delays every response.

SSR and performance testing

SSR moves rendering work from each visitor's device to your server, so your capacity now sets the page speed. Time to First Byte is the number to watch: web.dev rates 0.8 seconds or less as good and above 1.8 seconds as poor, and notes that a server-rendered page can have a higher TTFB but better First Contentful Paint and Largest Contentful Paint than a client-rendered one.

A single request tells you little. Run a load test against your key SSR routes with realistic traffic and watch how TTFB and error rates change as concurrent users rise. Afterwards, track Core Web Vitals over time with page speed monitoring. For the single-page-app side of the question, see how to load test single page applications, and for keeping regressions out, performance budgets for web apps.

FAQ: Server-Side Rendering

Is SSR better than SSG?

Neither is better in general. SSG fits content that changes rarely, because the HTML is built once and served from a CDN. SSR fits content that changes per request or per user. Many sites use both.

Does SSR fix SEO automatically?

It makes sure crawlers receive complete HTML, but you still need good titles, meta tags, structured data, internal links and acceptable Core Web Vitals.

Is SSR slower than CSR?

It depends on the metric. The server needs time to build the page, so TTFB is usually higher. The first paint is usually earlier because the HTML arrives ready to display. Interactivity depends on how much JavaScript must hydrate.

Can I mix SSR and CSR in one app?

Yes. Next.js, Nuxt and SvelteKit let you pick the rendering mode per route, so public pages can use SSR while a logged-in dashboard stays client-rendered.

How do I reduce TTFB on an SSR site?

Cache pages and data that are not personal, speed up or parallelise the queries behind the render, stream the response, and consider rendering at the edge. Measure again under load after each change.

Is SSR the same as React Server Components?

No. SSR produces HTML on the server for the first load, and the full component code is still sent to the browser to hydrate. Server Components run only on the server and send no component code for their part of the tree. They are often combined.