What is Server-Side Rendering?

Server-side rendering (SSR) generates a page’s initial HTML on the server and sends it to the browser. Client-side JavaScript may subsequently hydrate that HTML to provide interactive behavior.

How Server-Side Rendering works

SSR executes component rendering on a server for each request or from a server-side cache, producing an HTML representation that can be displayed before the application bundle runs. Hydration then attaches client logic to matching markup when interactivity is needed. This differs from static generation, which creates HTML ahead of requests, and from purely client-rendered pages that begin with a minimal shell. SSR sits in the web delivery path and can combine request context, backend data, and routing before response.

Key facts

  1. Hydration expects the client’s initial tree to match the server markup; locale, time, randomness, or browser-only branches can cause mismatches and discarded work.
  2. Server rendering can improve first-content availability, but slow backend data or uncached computation increases time to first byte unless work is streamed or cached.
  3. Code executed during SSR has no browser DOM, so modules that access window or document during import or render must be isolated behind a client boundary.

When Server-Side Rendering matters

Use SSR when initial content, link previews, search discovery, or resilience without JavaScript matters. It adds server rendering work and can cause hydration errors if browser output differs from the server HTML.

Turn media knowledge into a working pipeline

Connect uploads, processing, AI, storage, and delivery through one declarative API — with the encoding stack, scaling, and format churn handled for you.

Try Transloadit for free