Blog
3 min read

SSR vs CSR vs SSG: How Web Pages Get Rendered, Explained

Server-side rendering, client-side rendering and static site generation are three answers to one question: where and when is the HTML made? How each works, the trade-offs for speed, SEO, cost and freshness, ISR in between, and which to use for which page.

Every web page is HTML in the end. SSR, CSR and SSG are three answers to one question: where and when does that HTML get made?

CSR: client-side rendering

The server sends an almost empty HTML page plus a JavaScript bundle. The browser runs the JavaScript, fetches data from an API, and builds the page.

<body><div id="root"></div><script src="/app.js"></script></body>

A plain React + Vite app works this way. (What is Vite?)

  • ✅ Simple to host (just static files), app-like once loaded
  • ❌ Blank screen until JavaScript loads; weaker SEO and link previews; slow on cheap phones

SSR: server-side rendering

On every request, the server runs your code, fetches the data, builds the full HTML and sends it. The browser shows content immediately, then JavaScript "hydrates" it to make it interactive. (Hydration errors explained)

  • ✅ Fast first view, great SEO, always-fresh data, personalised pages
  • ❌ Needs a running server; each request costs server work; slow data = slow page

SSG: static site generation

HTML is built once, at build time, for every page. The finished files are served as-is — often from a CDN.

  • ✅ Fastest possible, cheapest to host, very robust
  • ❌ Content is only as fresh as the last build; impractical for millions of pages or per-user content

ISR: the bit in between

Incremental static regeneration (a Next.js term; other frameworks have equivalents) serves a static page but rebuilds it in the background after a set time or when you trigger it. Static speed, content that stays reasonably fresh.

Side by side

CSR SSR SSG
HTML made In the browser On the server, per request At build time
First view speed Slowest Fast Fastest
SEO Weakest Strong Strong
Data freshness Live Live As of last build
Hosting Static files A server Static files / CDN
Server cost Low Highest Lowest

Which to use for which page

You don't pick one for a whole app. Modern frameworks like Next.js, Astro, Nuxt and SvelteKit let you choose per page:

Page Good choice
Homepage, pricing, blog posts SSG (or ISR)
Product pages that change hourly ISR
Search results, personalised feeds SSR
Logged-in dashboard CSR or SSR — SEO doesn't matter
Admin tools CSR

How this shows up in Next.js

In the Next.js App Router, pages are rendered on the server by default, and are static when they don't depend on request data. Using cookies, headers or uncached data makes a page dynamic (SSR). Components marked "use client" add interactivity in the browser. (React Server Components explained, What is Next.js?)

Hosting implications

The summary

  • CSR: browser builds the page. Simple, weaker SEO.
  • SSR: server builds it per request. Fresh and SEO-friendly, needs a server.
  • SSG: built ahead of time. Fastest and cheapest, less fresh.
  • Mix them per page.

EasySpawn runs server-rendered and static apps on the same server, so you can use SSR, SSG and ISR wherever they fit without juggling hosts. See how it works or join the waitlist.

Related: SPA vs MPA · Static vs Dynamic Websites · Next.js App Router vs Pages Router · Astro vs Next.js

Keep reading