Server-Side Rendering (SSR)

What is server-side rendering?

Server-side rendering (SSR) means a web page’s HTML is generated on the server for each request and sent to the browser fully-formed, rather than sending a near-empty HTML shell and letting JavaScript build the page in the browser. When you request an SSR page, the server runs the application code, produces the complete HTML (with the actual content already in it), and returns that — so the browser can display meaningful content immediately, before any client-side JavaScript has to run. It’s one point on a spectrum of rendering strategies, and understanding where it sits (versus its alternatives) is more useful than memorizing SSR in isolation.

SSR vs CSR vs SSG vs ISR — the rendering spectrum

The real subject here is the tradeoff between four approaches. Client-side rendering (CSR) — the classic single-page-app model — ships a minimal HTML shell plus a JavaScript bundle; the browser downloads and runs the JS, which then fetches data and builds the page. Great for highly interactive apps after load, but the initial view is slow (blank until JS executes) and historically bad for SEO, because crawlers may see an empty shell. SSR flips this: the server does the work per request, so the user (and search crawlers) get real content on first paint — better perceived performance and SEO — at the cost of server compute on every request and more infrastructure complexity. Static site generation (SSG) pre-renders pages to static HTML at build time, so serving is as cheap and fast as handing out files from a CDN — ideal for content that doesn’t change per-request (blogs, docs, marketing) but not suitable for highly dynamic, personalized pages. Incremental Static Regeneration (ISR) is a hybrid that serves static pages but regenerates them in the background on a schedule or on-demand, getting much of SSG’s speed with fresher content. The honest guidance: there’s no universally “best” one — CSR for app-like interactivity where SEO doesn’t matter (dashboards behind login), SSR for dynamic content that needs good first-load and SEO, SSG for mostly-static content, ISR for static-but-periodically-updated. Modern frameworks (Next.js, Nuxt, Remix, Astro, SvelteKit) let you mix these per route, which is the actual modern practice — the question isn’t “which one for the whole app” but “which one for this page.”

The costs and complications people underestimate

SSR isn’t free, and its downsides are concrete. Server cost and load: rendering on every request consumes server CPU and memory, so a high-traffic SSR site needs more (and more carefully scaled) infrastructure than an SSG site served from a CDN — under heavy traffic, per-request rendering can become a bottleneck and a cost center. Time to First Byte can worsen if server rendering is slow (the browser waits for the server to finish rendering before receiving anything). Hydration is the subtle one: after SSR delivers HTML, the browser still downloads the JavaScript and “hydrates” the static markup to make it interactive — and if that JS is heavy, the page can look ready but be unresponsive to clicks for a moment (the “uncanny valley” of SSR), plus you’ve arguably done the work twice (once on server, once on client). This is why newer approaches (React Server Components, Astro’s islands, partial/streaming hydration) try to reduce the JavaScript shipped to the client. Caching SSR output (at a CDN or edge) is the standard mitigation for the server-cost problem, but caching per-request dynamic content is inherently tricky. The recurring mistakes: reaching for SSR reflexively when SSG or ISR would serve the content far more cheaply; ignoring hydration cost so the page is visually ready but interactively frozen; and running SSR at scale without caching, turning every page view into avoidable server work.

What people get wrong

• Defaulting to SSR when SSG/ISR fits — for content that isn’t per-request dynamic, static generation is dramatically cheaper and faster to serve.
• Ignoring hydration cost: SSR delivers HTML fast, but heavy client JS can leave the page looking ready while unresponsive to interaction.
• SSR at scale without caching — per-request rendering is real server compute; without CDN/edge caching it becomes a cost and performance bottleneck.

Primary source: Next.js: Rendering fundamentals