Server-Side Rendering

ssr · server-side rendering · server side rendering · server rendering · universal rendering · isomorphic rendering

Definition

Server-side rendering is the generation of HTML on the server before it is sent to the browser; it gives correct SEO indexation and a fast first paint, including for personalized content.

How SSR works

When a page is requested, the server does all the rendering work: it queries the database, applies
the template, builds the HTML and sends a finished document to the browser. The browser receives a
complete page with content and does not need to execute JavaScript for the first render.

SSR flow:
Browser → GET /product/123 → Server
  → fetch product data
  → fetch recommendations (API)
  → render HTML template
  → return full HTML

CSR flow:
Browser → GET / → Server → empty HTML + JS bundle
Browser → execute JS → fetch product/123 → render DOM

Comparing rendering approaches

Approach	SEO	First contentful paint	Personalization	Server load
SSR	Excellent	Fast	On the server	High
CSR	Poor	Slow	Client-side	Low
SSG	Excellent	Very fast	None or limited	Minimal
Hydration (SSR + CSR)	Excellent	Fast	Server plus client	Medium

SSR and personalization

Server rendering enables the highest-quality form of personalization: recommendations and
personalized content are embedded in the HTML on the server. The user sees a personalized page from
the first byte — no flicker, no flash of unstyled content, no wait for client-side initialisation.

That matters most for:

PLP — the ordering of products in a listing, personalized to the user
Homepage — a hero block with personalized recommendations
PDP — a similar products block with no loading delay

Important: with SSR personalization, API response time becomes critical. A call to the
recommendations API blocks HTML rendering. The answer is an aggressive recommendations cache, or
async SSR with parallel requests.

Caching in SSR

To reduce server load, SSR pages are cached at the CDN — which conflicts with personalization, since
you cannot serve different users the same cached HTML. The standard approaches:

Edge personalization — the cache holds the base HTML and personalization is added at the CDN
edge through a client-side script
Fragment caching — shared parts of the page are cached while personalized fragments are
generated fresh
Cookie-based routing — the CDN reads the user’s segment and serves the matching cache variant

Frequently asked questions

How does SSR differ from client-side rendering?

With client-side rendering the server returns an empty HTML shell plus JavaScript, and the browser renders the content itself. A crawler sees an empty page, or content only after a delay. With SSR the server returns finished HTML, so both crawler and user see the content immediately. The trade-off: SSR costs server computation on every request.

What is hydration in an SSR application?

Hydration is the process in which the browser brings the static HTML it received from the server to life by attaching JavaScript event handlers to it. Before hydration the page is visible but not interactive. After it, the page behaves like a full SPA. Slow hydration is a common cause of poor time to interactive.

When should you choose SSR over static site generation?

SSR suits pages with frequently changing data — prices, stock levels, personalized content. Static generation suits stable pages such as blog articles and landing pages. A hybrid approach, as in Next.js, lets both methods coexist on different pages of the same application.

How does SSR interact with personalization?

SSR opens up server-side personalization: the backend calls the recommendations API and places the result straight into the HTML. The user sees personalized content with no delay and no flicker. The trade-off: server response time now depends on the personalization API's SLA — a slow answer blocks rendering.