CSR, SSR, SSG, and ISR — what they actually mean

Four acronyms, one problem: how do you get HTML to the browser? Each strategy makes a different tradeoff between speed, freshness, and server cost. Here's what they each do — and when to use them.

---

CSR — Client-Side Rendering

The browser does all the work

With CSR, the server sends a nearly empty HTML shell — usually just a <div id="root"> — along with a JavaScript bundle. The browser downloads that bundle, executes it, fetches data, and builds the page entirely on the client.

This is the default approach for React apps created with Create React App or Vite. It's simple and fast to develop, but the user sees a blank or loading screen until JavaScript finishes executing.

Request → Empty HTML → Download JS → Fetch data → Render UI

• Best for: Dashboards, SaaS apps, anything behind a login
• Watch out for: Poor SEO, slow initial load on low-end devices

---

SSR — Server-Side Rendering

The server builds the page on every request

With SSR, when a request arrives, the server fetches data, renders the complete HTML, and sends it to the browser. The user sees content immediately — no waiting for JavaScript to download and run. The page then "hydrates" so React (or Vue, etc.) takes over for interactivity.

This is what Next.js does with getServerSideProps. The content is always fresh because it's generated per-request, but that means every page load hits your server.

Request → Server fetches data → Render HTML → Send to browser → Hydrate

• Best for: Personalised pages, real-time data, e-commerce
• Watch out for: Higher server costs, slower TTFB under heavy load

---

SSG — Static Site Generation

HTML is built once at deploy time

SSG generates all your pages ahead of time — at build — and stores them as plain HTML files. When a user requests a page, they get that pre-built file instantly from a CDN. There's no server logic at runtime, so it's blazingly fast and virtually free to serve.

Gatsby pioneered this, and Next.js supports it with getStaticProps. The catch: if your content changes, you have to redeploy the whole site.

Build time → Fetch all data → Generate HTML files → Deploy to CDN

• Best for: Blogs, docs, marketing sites, portfolios
• Watch out for: Stale content, long build times on large sites

---

ISR — Incremental Static Regeneration

Static pages that quietly refresh themselves

ISR is Next.js's answer to the SSG freshness problem. Pages are still pre-built and served from a CDN like SSG — but they automatically regenerate in the background after a defined time interval. A user hits a stale page once, the server queues a rebuild, and the next visitor gets the fresh version.

You get the performance of static files with content that stays reasonably up-to-date, without a full redeploy. It's a pragmatic middle ground, though not suitable for data that must be current to the second.

Build time → Static HTML → Serve from CDN → Revalidate in background

• Best for: Product pages, news articles, catalogue sites
• Watch out for: That first stale-while-revalidate request still serves old data

---

At a glance

---

There's no universally "correct" choice — most real-world applications mix strategies. A Next.js app might SSG its marketing pages, SSR its checkout flow, and CSR its account dashboard. Understanding the tradeoffs is what lets you choose the right tool for each route.