What is Server-Side Rendering (SSR)? How it works and when to use it

When you type a URL into a browser and hit Enter, something has to build the page you see. That "something" can happen in two main places: on a server before the page is sent, or in your browser after it arrives. Server-side rendering is the first approach — it is the practice of generating HTML content on the server and sending the fully built page to the client.

How server-side rendering works

Here is what happens step by step when a server renders a page:

1. A user types a URL or clicks a link, and the browser sends a request to the server.
2. The server processes the request — identifying which page is needed and running any backend logic.
3. The server fetches the data required for that page — pulling from a database, an API, or other sources.
4. The server inserts that data into an HTML template, building the complete HTML document.
5. The server sends the finished HTML to the browser as an HTTP response.
6. The browser receives the HTML and renders it immediately, showing content without waiting for JavaScript to load.

This is in contrast to client-side rendering, where the server sends a near-empty HTML shell and the browser must download, parse, and execute JavaScript before any content appears.

Server-side rendering vs. client-side rendering vs. static rendering

Understanding SSR means understanding the alternatives:

Client-side rendering (CSR)

With client-side rendering, the server sends minimal HTML (usually just an empty <div> and a JavaScript bundle). The browser downloads the JavaScript, runs it, and uses it to build the page content inside the DOM. The browser has to do all the work of fetching data and rendering after the initial JavaScript download is complete.

This approach enables rich, interactive single-page applications (SPAs). But it creates a waterfall of requests: the browser renders the initial HTML, then discovers it needs data, then fetches the data, then renders it. Users see a blank or loading screen during this process.

Static site generation (SSG)

Static rendering happens at build time, not at request time. The server (or build tool) pre-generates HTML files for every URL ahead of time, and those files are served directly from a CDN on each request. There is no server-side computation per request, so TTFB is consistently fast.

SSG works best when the content does not change frequently — blogs, documentation, marketing sites. For sites with millions of dynamic pages or frequently changing content, pre-generating every possible page is infeasible.

SSR in context

SSR fills the gap between static sites and fully client-rendered apps. It generates HTML on demand per request, so it can serve fresh, personalized, or dynamic content while still delivering a complete HTML page to the browser. The trade-off is that every request requires server-side computation, which adds latency compared to serving a pre-built static file.

Modern frameworks handle SSR in different ways. React supports SSR via renderToString() or the newer streaming server DOM APIs (renderToPipeableStream, renderToReadableStream). Vue has a server-side rendering guide and the Nuxt framework. Angular offers Angular Universal. Next.js is built around SSR as a core feature.

Benefits of server-side rendering

Improved SEO and crawlability

Search engines can crawl and index server-rendered pages more easily. Because the full HTML is present in the initial response, crawlers do not need to execute JavaScript to read the content. Social media previews (Facebook, Twitter, LinkedIn) similarly rely on HTML being present in the initial response — they often cannot execute JavaScript at all. MDN notes that while major search engines can run JavaScript, social media crawlers typically cannot, making SSR valuable for link previews.

Faster first contentful paint

Because the browser receives complete HTML, it can render content immediately upon receiving the first bytes. There is no wait for a large JavaScript bundle to download, parse, and execute before content appears. This leads to a faster First Contentful Paint (FCP), which is one of Google's Core Web Vitals.

Better performance on low-powered devices

Server-rendered pages send text and links, not JavaScript and its execution engine. For users on slow devices, old hardware, or in environments where JavaScript is unavailable or disabled, an SSR page is more accessible. MDN's SSR glossary describes this as "the page is somewhat usable without JavaScript" — interactive features relying on JavaScript will not work, but the content is readable.

Reduced client-side JavaScript

Server-side rendering lets you avoid sending large JavaScript bundles to the client. With less JavaScript to parse and execute, the main thread is less busy, which means a lower Total Blocking Time (TBT) and a lower Interaction to Next Paint (INP) — both Core Web Vitals.

Disadvantages of server-side rendering

Increased time to first byte

Generating HTML on the server for every request takes compute time. If the server is under load or the page is complex, TTFB can suffer compared to serving a pre-built static file. Solutions like edge caching, CDN-level caching, and streaming HTML can reduce this gap.

Higher server load

Every page request requires server-side computation — routing, data fetching, template rendering, serialization. For high-traffic sites, this can mean significant server costs. Caching rendered HTML at the CDN or application level is the standard mitigation.

Complexity of caching

Dynamic content is harder to cache effectively. A page that varies per user or changes frequently requires careful cache-invalidation logic. Getting caching "right" with SSR involves managing stale-while-revalidate patterns, cache tags, and CDN-level purge strategies.

Hydration overhead

Many SSR frameworks send a fully rendered HTML page but then also send a JavaScript bundle that "takes over" the existing DOM — a process called hydration. This means the same content is effectively rendered twice: once on the server and once on the client. Hydration adds JavaScript parsing and execution cost even on pages that do not need heavy interactivity. Modern approaches like React Server Components and resumability aim to reduce or eliminate this overhead.

How frameworks implement SSR

Next.js (React)

Next.js was built around SSR as a core concept. By default, pages in Next.js are server-rendered. You can opt into static generation with getStaticProps, or incremental static regeneration (ISR) to rebuild pages in the background on a schedule. Next.js App Router introduced React Server Components, which execute only on the server and send zero JavaScript to the client for those components.

Nuxt (Vue)

Nuxt is the SSR framework for Vue. It handles routing, data fetching, and rendering on the server, and it sends a Vue app to the client for hydration. Nuxt 3 added hybrid rendering, letting you mix SSR, SSG, and ISR on different routes within the same application.

Angular Universal

Angular Universal runs Angular applications on the server using Node.js or .NET backends. It renders the initial view on the server, sends it to the client, and then "bootstraps" the Angular app in the browser to take over.

Streaming SSR

Traditional SSR sends the HTML document in one piece after the entire page is ready. Streaming SSR sends the document in chunks as they become available, letting the browser start parsing and rendering before the entire response is complete. React's renderToPipeableStream and renderToReadableStream support streaming. This improves perceived performance for pages where some content (like a navigation bar or hero section) is ready before data for a slow section is fetched.

FAQ

What is the difference between server-side rendering and client-side rendering?

Server-side rendering generates the complete HTML on the server and sends it to the browser in the HTTP response. Client-side rendering sends minimal HTML and relies on JavaScript running in the browser to build the page content. SSR produces a faster first paint and better SEO; CSR allows richer client-side interactivity without page reloads. Both approaches can be used together in the same application.

Does server-side rendering improve SEO?

Yes. Search engines can read SSR pages without executing JavaScript, which makes indexing more reliable. Social media platforms that cannot run JavaScript also benefit from the complete HTML in the initial response. However, modern search engine crawlers (Googlebot) can execute JavaScript, so CSR pages can also be indexed — though with potential delays and more complexity.

What is hydration in server-side rendering?

Hydration is the process of attaching client-side JavaScript to a server-rendered HTML page so that the page becomes interactive. The browser renders the HTML from the server, then downloads and runs the JavaScript bundle, which attaches event listeners and initializes the application state. This "re-renders" the page on the client in a process called rehydration. The term rehydration emphasizes that the server-rendered content is being "filled in" with client-side interactivity after the initial HTML arrives.

Is server-side rendering faster than client-side rendering?

For the initial page load, SSR is generally faster because the browser renders HTML immediately without waiting for JavaScript. For subsequent interactions after the page loads, CSR applications can feel faster because navigating between pages does not require a full server round trip. The best choice depends on your use case — content-heavy sites benefit from SSR, while highly interactive applications benefit from CSR.

Can I mix SSR and CSR in the same application?

Yes. Many modern frameworks support a hybrid approach. For example, Netflix server-renders its landing pages for fast initial loads, then prefetches the JavaScript for interactive pages. This gives users the best of both: fast first paint from SSR, and rich interactivity from CSR after the page loads.

Summary

Server-side rendering generates the complete HTML for a page on the server in response to each request, delivering a fully populated page to the browser. It improves SEO and crawlability, produces faster first contentful paint, and reduces the JavaScript burden on the client — but it increases server-side compute costs and TTFB compared to serving static files.

The choice between SSR, SSG, and CSR is not binary. Modern frameworks let you mix approaches per route, choosing SSR for pages that need fresh dynamic content, SSG for evergreen content, and CSR for highly interactive application areas. Understanding what each rendering strategy costs and delivers helps you make the right call for your specific project.

For content-heavy sites, blogs, e-commerce product pages, and marketing sites — where crawlability and first-paint speed matter most — SSR is a strong default. For dashboard-style applications, real-time collaborative tools, and pages with heavy user interaction, CSR or hybrid rendering may serve users better.