What is server-side rendering?

Every web page has to turn data and templates into HTML. The question is where that conversion happens and at what moment. When the work happens on the machine answering the request, the browser receives a document that already contains the text, the links and the structure.

The opposite approach is client-side rendering. There the server returns almost empty HTML together with a JavaScript bundle, and the browser builds the interface only after downloading and executing that code. The user sees a blank screen until the process finishes, and any bot that does not execute JavaScript sees exactly the same thing.

Between the two extremes sits static rendering, also called prerendering. The HTML is generated once at build time and served identically to every visit. The difference from SSR is not in what reaches the browser but in when it is generated: static produces the HTML before the request exists, SSR produces it during the request. That is why static suits catalogues and documentation that rarely change, while SSR suits content that depends on the person, on stock levels or on the time of day.

Three labels coexist for the same thing: server-side rendering, rendering on the server and the abbreviation SSR.

The path starts with an HTTP request. The server receives the URL, resolves the route, queries whatever data sources are needed and runs the same component code the browser would otherwise run. The result is an HTML string that travels as the body of the response.

The browser can paint that HTML as soon as it arrives, without waiting for JavaScript. Then comes the second half of the process: the client bundle is downloaded and hydration runs, attaching state and event handlers to the HTML that is already there. Until hydration finishes, the page looks complete but does not respond to clicks.

The difference in the document that travels over the wire shows up when the two cases are compared:

<!-- Client: the HTML arrives empty -->
<div id="app"></div>
<script src="/bundle.js"></script>

<!-- SSR: the HTML carries content -->
<div id="app">
  <h1>Trail running shoes</h1>
  <p>Price: 119 euros</p>
</div>
<script src="/bundle.js"></script>

For search engines the path is different. Google's documentation describes three chained phases: crawling, rendering and indexing. Pages that answer with status 200 enter a rendering queue, a headless Chromium processes them once resources allow, and the resulting HTML is what gets indexed. The text itself warns that the wait in that queue usually lasts a few seconds, though it can take longer. When the HTML comes from the origin, that step stops being the fragile point, because the content is already in the first response.

What gets decided here is which template is generated where. The choice of framework is secondary. A product page with changing price and availability, a search with filters and a profile page do not tolerate the same answer as a blog article.

The first effect is indexability. If the main content only appears after JavaScript runs, its route into the index depends on rendering completing without incident. A script that fails, a resource blocked in robots.txt or an API call that times out leave an empty page as far as the search engine is concerned. When the HTML is built at the origin, that risk disappears.

The second effect is speed. Sending already rendered content brings the first paint forward and usually improves LCP, because the main element does not wait for a JavaScript bundle. In exchange, generating the HTML on every request consumes server time and worsens TTFB compared with a static response stored in advance.

It is worth saying plainly: SSR is not a ranking factor, and no documentation presents it as one. What is documented is its effect on indexability and on loading metrics. Those two things shape how a page performs in results, and that is the real connection.

• Decide the strategy per template rather than for the whole site: what changes on every visit calls for SSR, what is stable can be served already generated.
• Put everything that should be indexed into the initial HTML: title, main text, internal links, canonical tag and robots directives.
• Compare the source HTML with the rendered HTML in the Search Console URL Inspection tool, using one template of each type, not just the homepage.
• Do not block in robots.txt the JavaScript and CSS files the page needs in order to render.
• Put a caching layer in front of the rendering (CDN, page cache or data cache) to contain the cost in TTFB.
• Keep an eye on hydration by measuring INP and reducing the JavaScript shipped, because a visible page that does not respond to clicks is still slow for the person using it.

• Assuming the search engine does not execute JavaScript. It does, but in a later phase and subject to available resources, which turns every script failure into a risk of missing content.
• Serving bots different HTML from what the person receives. If the difference is substantial, it stops being a rendering decision and becomes cloaking.
• Applying SSR to every route without caching and discovering the cost later, on the server bill and in a TTFB that climbs at peak hours.
• Confusing “the HTML arrives complete” with “the page is ready”. Hydration can take time and block interaction for several seconds.
• Leaving dynamic rendering in place as a permanent solution. Google describes it as a workaround it does not recommend, and proposes server-side rendering, static rendering or hydration instead.