What is Server-Side Rendering (SSR)?
Server-side rendering (SSR) generates a page's HTML on the server at the moment it is requested, so the browser receives a complete, ready-to-display page instead of an empty shell that JavaScript fills in afterwards. This typically improves initial load speed and makes content immediately visible to search engine crawlers without executing JavaScript first. The trade-off is more server load per request compared to serving pre-built static files, and SSR is one of several rendering strategies alongside static site generation and client-side rendering.
Server-side rendering is a technique where a web page's HTML is generated on the server for each request and sent to the browser fully formed, rather than being built up in the browser by JavaScript.
The problem SSR solves
Modern websites are often built with JavaScript frameworks like React, Vue, or Next.js, which by default can render pages entirely in the browser: the server sends a nearly empty HTML file plus a JavaScript bundle, and the browser executes that JavaScript to build the actual visible content. This approach, client-side rendering, works but has two well-known downsides. Users see a blank page or loading spinner until the JavaScript downloads, parses, and runs, which can take a noticeable moment on a slow connection or older device. And search engine crawlers, along with social media link previews, may see an empty page if they do not execute JavaScript, or execute it only partially.
Server-side rendering addresses both issues by moving the rendering work to the server. When a request comes in, the server runs the same component code that would otherwise run in the browser, produces the finished HTML, and sends that directly. The browser can display real content immediately, and any crawler reading the raw HTML response sees the full page without needing to run any JavaScript first.
How it actually works
On each request, the server executes the application’s rendering logic, often fetching whatever data the page needs, a user’s account details, a product listing, a search result, and assembles that into a complete HTML document. This HTML is sent to the browser, which displays it right away. JavaScript then loads in the background and “hydrates” the page, attaching the interactive behaviour, button clicks, form handling, dynamic updates, to the HTML that is already visible. The user sees content immediately and gains interactivity a moment later, rather than waiting for both at once.
This per-request rendering is the key distinction from static site generation, where the HTML is built once ahead of time and reused for every visitor. SSR trades that reuse for the ability to include fresh or personalised data on every load.
SSR versus the alternatives
Client-side rendering keeps the server simple, since it only serves static files and an API, but delays visible content until JavaScript runs, which can hurt both perceived performance and, historically, SEO. Static site generation produces the fastest possible delivery, since pages are pre-built and can be served straight from a content delivery network with no per-request computation, but it only works well for content that is the same for every visitor. Server-side rendering sits between the two: slower to serve than a static file because the server must do work on every request, but able to reflect real-time, per-user data that static generation cannot.
Many modern frameworks let you mix strategies on a per-page basis: a marketing homepage generated statically, a user dashboard rendered server-side, and a highly interactive widget rendered client-side, all within the same application.
Why this matters for performance and SEO
Server-side rendering directly affects metrics like Largest Contentful Paint, one of the Core Web Vitals Google uses as a ranking signal, since content becomes visible sooner than with a pure client-side rendered page. It also removes uncertainty around whether search engines and social platforms correctly render your JavaScript before indexing or generating link previews, since the HTML they receive already contains the full content.
The main cost is server load: every visit triggers a fresh rendering pass rather than serving a cached static file, so SSR applications typically need more server capacity or caching strategies layered on top as traffic grows. This is a relevant consideration for applications like progressive web apps as well, where the initial page load experience matters for installability and perceived speed even after the app takes over client-side.
Our tip: Do not apply server-side rendering to every page by default. Use it where pages genuinely need fresh or personalised data on each visit, and fall back to static generation for content that is the same for everyone; mixing both within one site is standard practice and usually the most cost-effective approach.
Frequently asked questions
What is the difference between server-side rendering and client-side rendering?
With client-side rendering, the server sends a mostly empty HTML page along with a JavaScript bundle, and the browser runs that JavaScript to build the visible content after the page loads. With server-side rendering, the server does that work upfront and sends a complete HTML page immediately. Client-side rendering can leave users looking at a blank screen or loading spinner while the JavaScript downloads and runs; server-side rendering shows the actual content as soon as the page arrives, then JavaScript takes over for interactivity.
Is server-side rendering better for SEO?
Generally yes, especially historically. Search engines can read fully rendered HTML immediately, while content that only appears after client-side JavaScript execution requires the crawler to execute that JavaScript first, which not all crawlers do reliably or promptly. Google has improved its ability to render JavaScript-heavy pages over the years, but server-side rendering remains the safer, more predictable choice when search visibility matters, since content is guaranteed to be present in the initial HTML response.
How does server-side rendering differ from static site generation?
Static site generation builds every page's HTML once, in advance, at build time, and serves the identical file to every visitor from a fast content delivery network. Server-side rendering builds the HTML fresh for each individual request, which allows the page to reflect real-time or personalised data, a logged-in user's dashboard, live pricing, but requires the server to do that rendering work on every single visit. Static generation is faster and cheaper to serve; SSR is more flexible for dynamic content.
When should a business choose server-side rendering over static generation?
Choose server-side rendering when pages need to reflect data that changes per request or per user: a personalised dashboard, live search results, real-time inventory, or content behind a login. Choose static generation instead when content is the same for every visitor and changes infrequently, such as most marketing pages, blog posts, or documentation, since static files are cheaper to serve and load faster from a content delivery network with no per-request rendering cost.