Server-side rendering: plainly explained.

Server-side rendering, or SSR, is a technique where a web server generates a page's complete HTML for each incoming request, before sending it to the browser. The visitor receives a fully formed page immediately, rather than a near-empty HTML shell that only fills in once JavaScript downloads, executes, and fetches data. This matters both for visitors on slow connections, who see meaningful content sooner, and for search engine crawlers, which can read the page's content without having to execute JavaScript first.

SSR sits opposite client-side rendering, where the server sends a minimal HTML file and a JavaScript bundle that builds the actual page content in the browser after it loads. Most modern frameworks now support both modes, and many production sites mix them depending on the page.

On each request, the server runs the application code, fetches any data the page needs, and renders the resulting markup into an HTML string before sending it as the response:

// simplified SSR request handler
app.get('/product/:id', async (req, res) => {
const product = await fetchProduct(req.params.id);
const html = renderToString(<ProductPage product={product} />);
res.send(`<html><body>${html}</body></html>`);
});

The browser then loads a JavaScript bundle that attaches event handlers to that existing HTML, a step called hydration, so the page becomes interactive without the browser having to build the markup from scratch.

• Classic SSR: HTML is rendered fresh on the server for every request.
• Static site generation: pages are rendered once at build time and served as static files, no per-request server work.
• Incremental static regeneration: static pages are regenerated in the background on a schedule or on demand, combining static speed with fresher content.
• Streaming SSR: the server sends HTML in chunks as it becomes ready, letting the browser start rendering before the full page has finished generating.

• Cache rendered HTML where content does not change per visitor, to avoid re-running the full render on every request.
• Keep the data fetching a page needs for its initial render as small as possible; a slow database query on the server delays the entire response.
• Match server and client rendering output exactly, since a mismatch during hydration causes visible flicker or React hydration warnings.
• Consider static site generation instead of full SSR for pages whose content rarely changes, since it removes per-request server cost entirely.
• Monitor server response time under load: SSR shifts rendering cost from the visitor's device to the server, which needs to scale accordingly.

Search engines can index client-rendered pages, but SSR removes any uncertainty by delivering complete, crawlable HTML on the very first response, which is particularly valuable for content-heavy sites, e-commerce catalogs, and blogs where organic search traffic matters. SSR also tends to improve the perceived loading speed for visitors, since meaningful content appears before the full JavaScript bundle has finished downloading and running, which benefits Core Web Vitals metrics like Largest Contentful Paint.

When we build custom web applications, we choose between server-side rendering, static generation, and client-side rendering based on how often a page's content changes and how much organic search traffic it needs to capture, rather than defaulting to one approach for every project. See our web apps service for how we architect the applications and frameworks we build for clients.