Server-side rendering

Server-side rendering (SSR) generates a page's full HTML on the server per request, so the browser gets ready-to-display content instead of an empty shell.
Webapp
Created on
28.09.2026

Summarize this

What is server-side rendering?

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.

‍

How server-side rendering works

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.

‍

SSR variants

  • 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.

‍

Server-side rendering vs client-side rendering

Aspect Server-side rendering Client-side rendering
First content visible Immediately, in the initial HTML After JavaScript downloads and runs
SEO out of the box Strong, no JavaScript execution needed Depends on the crawler executing JavaScript
Server load Higher, work done per request Lower, work done in the browser

‍

Best practices and common pitfalls

  • 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.

‍

Why it matters for SEO and performance

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.

‍

Server-side rendering at BeBranded

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.

FAQ

It is used to generate a page's full HTML on the server before sending it to the browser, so visitors and crawlers see complete content immediately instead of a blank page waiting for JavaScript.
Generally yes: search engine crawlers receive fully formed HTML immediately, removing any dependency on JavaScript execution to see the page's content.
SSR renders a page on the server for every request, while static site generation renders pages once at build time and serves the same static file to every visitor.
It adds server processing time per request compared to serving a pre-built static file, but it usually still delivers content faster to the visitor than pure client-side rendering.
Yes. Frameworks built for single-page applications commonly offer an SSR mode that renders the initial page on the server, then hands off interactivity to client-side JavaScript.
Hydration is the step where the browser attaches JavaScript event handlers to the server-rendered HTML, turning static markup into an interactive page without re-rendering it from scratch.

Ready to boost your conversions?

Our team is here to understand your needs & work with you to create your next projects.
Get news, infos and resources.
Actionable tips delivered straight to your inbox.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.