CSR vs SSR vs SSG vs ISR — Which Rendering Pattern and When

Hey everyone, Richa here! 👋

Day 21. Week 5. Performance week.

And we're starting with the question that trips up almost every senior React interview candidate.

"Walk me through CSR, SSR, SSG, and ISR. When would you use each?"

I've seen devs who have shipped production apps for years stumble on this. Not because they don't know what the letters stand for — but because they haven't thought carefully about why each pattern exists and what tradeoffs you're actually making.

Today we fix that.

The core question — when does HTML get generated?

All four patterns are answering the same question: at what point does the HTML that the browser receives get created?

At build time?
On every request on the server?
In the browser after JS loads?
At build time but refreshed occasionally?

That question — and the tradeoffs around it — is what separates the four patterns.

rendering gif

CSR — Client-Side Rendering

What happens:

Browser requests the page
Server returns a near-empty HTML shell: <div id="root"></div>
Browser downloads the JavaScript bundle
JavaScript runs, React renders the UI, data is fetched
User sees content

Browser → Server → empty HTML → download JS → run JS → render → fetch data → show content

The tradeoff:

✅ Simple to deploy (just static files — Netlify, Vercel, S3)
✅ After first load, navigation is instant (SPA)
✅ Cheap to host
❌ Slow Time to First Contentful Paint (user sees blank screen while JS loads)
❌ SEO is poor (search crawlers see the empty HTML shell, not the content)
❌ Performance on low-end devices is bad (JS bundle runs on the user's device)

When to use it:

Dashboards and admin panels (authenticated users, SEO doesn't matter)
Internal tools
Apps where the content is entirely user-specific (no point indexing it anyway)
Prototypes and MVPs

// CSR — Vite + React SPA
// main.tsx
ReactDOM.createRoot(document.getElementById('root')!).render(<App />);

// Data fetched client-side
function DashboardPage() {
  const { data: stats } = useQuery({ queryKey: ['stats'], queryFn: fetchStats });
  return <Dashboard stats={stats} />;
}

SSR — Server-Side Rendering

What happens:

Browser requests the page
Server runs React, fetches data, generates full HTML
Server returns complete HTML with content
Browser displays HTML immediately (fast First Contentful Paint)
JavaScript downloads and "hydrates" — makes the page interactive

Browser → Server → fetch data + render HTML → full HTML → display immediately → download JS → hydrate

The tradeoff:

✅ Fast First Contentful Paint — user sees content immediately
✅ Great SEO — crawlers see full HTML
✅ Works well for personalised content (renders per-request with user data)
❌ Slower Time to First Byte (server has to fetch data and render before responding)
❌ More expensive — you need a running server, not just static files
❌ More complex infrastructure

When to use it:

E-commerce product pages (SEO critical, personalised pricing/stock)
News articles and blogs where content changes frequently
Pages that need user-specific data on first load (inbox, feed)

// SSR — Next.js App Router (React Server Components)
// app/products/[id]/page.tsx

export default async function ProductPage({ params }: { params: { id: string } }) {
  // This runs on the server — no client-side fetch, no loading state
  const product = await productService.getById(params.id);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <p>£{product.price}</p>
    </div>
  );
}

SSG — Static Site Generation

What happens:

At build time — framework runs React, fetches all data, generates HTML files
HTML files are deployed to a CDN
Browser requests the page → CDN returns pre-built HTML instantly
JavaScript hydrates the page

Build time: fetch data → render → generate HTML files → deploy to CDN
Request time: Browser → CDN → pre-built HTML → instant display → hydrate

The tradeoff:

✅ Fastest possible load time — HTML served from CDN edge, no server computation
✅ Excellent SEO
✅ Highly scalable — a CDN can handle millions of requests
✅ Cheapest hosting
❌ Content is stale until next build — real-time data is not possible
❌ Build time grows with page count (10,000 product pages = very slow build)
❌ Not suitable for user-specific content

When to use it:

Marketing sites and landing pages
Documentation sites
Blogs (content changes rarely)
Product catalogue pages where content changes infrequently

// SSG — Next.js App Router
// app/blog/[slug]/page.tsx

// generateStaticParams tells Next.js which pages to pre-build
export async function generateStaticParams() {
  const posts = await blogService.getAllSlugs();
  return posts.map(post => ({ slug: post.slug }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await blogService.getBySlug(params.slug);
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

ISR — Incremental Static Regeneration

What happens:

ISR is SSG with a time-based refresh. Pages are pre-built at build time — but after a set interval, the next request triggers a background rebuild of that page. The stale page is served immediately, and the rebuilt version is served from then on.

Build time: generate HTML → deploy to CDN
First request: serve pre-built HTML instantly
After revalidate window: next request triggers background rebuild
Subsequent requests: serve fresh rebuilt HTML

The tradeoff:

✅ Near-instant load (from CDN like SSG)
✅ Content stays relatively fresh without a full rebuild
✅ Scales like SSG (CDN, not server)
❌ Content can be stale for up to revalidate seconds
❌ First request after stale window still serves old content (subsequent gets new)

When to use it:

E-commerce product pages (prices change, but 60-second staleness is acceptable)
News sites (articles update occasionally, not every second)
Any SSG content that needs periodic refresh without full rebuilds

// ISR — Next.js App Router
// app/products/[id]/page.tsx

export const revalidate = 60; // rebuild this page at most every 60 seconds

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await productService.getById(params.id);
  return (
    <div>
      <h1>{product.name}</h1>
      <p>£{product.price}</p>
    </div>
  );
}

One line of config. The page is served from CDN instantly. Every 60 seconds, the next request triggers a background rebuild.

Mixing patterns — the real world

Real apps don't use just one pattern. Next.js (and modern React frameworks) let you mix them at the page or even component level.

myapp.com/                  → SSG  (marketing landing page, never changes)
myapp.com/blog/[slug]       → ISR  (posts change weekly, 1 hour revalidate)
myapp.com/products/[id]     → ISR  (prices change, 60 second revalidate)
myapp.com/dashboard         → SSR  (user-specific, personalised on server)
myapp.com/admin             → CSR  (internal tool, auth required, SEO irrelevant)

Each route uses the pattern that fits its content and performance requirements.

The decision framework

Ask these three questions:

1. Does this page need to be indexed by search engines?

No → CSR is fine (admin, dashboard, authenticated pages)
Yes → SSG, ISR, or SSR

2. How often does the content change?

Never / rarely → SSG (build once, serve forever)
Occasionally (minutes to hours) → ISR (rebuild periodically)
Every request / user-specific → SSR (render on every request)

3. Is the content personalised per user?

No → SSG or ISR (same HTML for everyone)
Yes → SSR (render per-request with user data)

Pattern	HTML created	SEO	Fresh content	User-specific	Cost
CSR	In browser	❌ Poor	✅ Always	✅ Yes	💰 Cheap
SSR	Per request on server	✅ Great	✅ Always	✅ Yes	💰💰 Server needed
SSG	At build time	✅ Great	❌ Stale until rebuild	❌ No	💰 Cheapest
ISR	Build + periodic refresh	✅ Great	⚠️ Up to N seconds stale	❌ No	💰 Cheap (CDN)

Today's takeaway

movie

These aren't just Next.js implementation details. They're fundamental architecture decisions that affect SEO, performance, infrastructure cost, and user experience.

The senior answer to "which rendering pattern would you use?" is never just one word. It's:

"It depends on whether the content needs SEO, how often it changes, and whether it's user-specific. For this app I'd use ISR for the product pages, SSR for the user dashboard, and SSG for the marketing pages."

That level of thinking — and being able to justify each choice — is what senior interviews are looking for.