Server-Side Rendering (SSR)

Server-Side Rendering (SSR) is the practice of rendering a page's HTML on the server in response to a request, then sending the fully formed markup to the browser, optionally followed by JavaScript that hydrates the page for interactivity. SSR contrasts with Client-Side Rendering (CSR), where the server returns a near-empty HTML shell and the browser builds the UI from JavaScript.

Why SSR matters

• Faster first paint. Users see content before JavaScript downloads and parses.
• SEO. Crawlers see real content immediately; helpful even though modern Googlebot also runs JS.
• Lower client cost. Less work for the user's device, especially on low-end hardware.
• Personalised content. Per-request data can be embedded directly in the initial HTML.

Related rendering modes

• SSG (Static Site Generation). Render at build time; serve from CDN. Cheapest at scale; freshest content updates require rebuild.
• ISR (Incremental Static Regeneration). Static pages refreshed in the background after a TTL; combines SSG cost with SSR-like freshness.
• Streaming SSR. Server flushes HTML in chunks as parts of the page resolve; React Suspense, Astro, Qwik.
• Edge rendering. SSR at the edge for low global latency (Vercel Edge, Cloudflare Workers, AWS Lambda@Edge).

Hydration

After SSR delivers HTML, the browser downloads the framework and re-runs components against the server-rendered DOM to attach event listeners and state. Frameworks like Qwik and Astro reduce this cost via resumable execution or no-hydration islands.