Skip to content
GeeksSmith
intermediate 8 min read

SSR, SSG, ISR & CSR Rendering Architectures

Next.js rendering strategies define where and when HTML and data are generated: CSR (Browser on demand), SSR (Server on every request), SSG (Build time at edge), and ISR (Static with background regeneration).

Why it matters in interviews

Choosing the wrong rendering strategy destroys Time to First Byte (TTFB) or serves stale e-commerce pricing. Interviewers expect a Lead engineer to choose the right strategy based on SEO, personalization, and traffic volume trade-offs.

Visual & Interactive Explanation

Next.js Rendering Strategies Comparison Matrix

Interactive Comparison

SSG

Static Site Generation

Edge CDN (Fastest)
Build TimeGenerated during `next build`
TTFB~10-30ms (Edge CDN)
Server Load0 compute per request
Best ForDocumentation, Blogs, Marketing
Strengths
  • Instant TTFB globally
  • Cheapest hosting cost
Trade-offs
  • Requires full rebuild to update content

ISR

Incremental Static Regeneration

Static + Fresh
RegenerationBackground revalidate / On-Demand
TTFB~15-40ms (Edge CDN)
Server LoadOnly runs when cache is stale
Best ForE-commerce product pages, news
Strengths
  • Speed of SSG without full site rebuilds
  • On-demand revalidateTag() support
Trade-offs
  • First visitor after expiry sees stale HTML

SSR

Server-Side Rendering

Dynamic / Real-time
Render TimeOn every HTTP request
TTFB~150-400ms (Server compute)
Server LoadCPU computation per request
Best ForUser Dashboards, Live Analytics
Strengths
  • Always 100% fresh data
  • Access to request headers & cookies
Trade-offs
  • Higher TTFB
  • Higher server CPU costs

CSR

Client-Side Rendering

Browser Only
Render TimeBrowser downloads & runs JS
TTFBFast HTML shell, slow data paint
SEORequires crawler JS execution
Best ForInternal admin tools, behind auth
Strengths
  • Zero server rendering load
  • Rich local interactive states
Trade-offs
  • Blank white screen during initial load
  • Poor SEO

Code Examples & Implementation

ISR and On-Demand Tag Revalidation in Next.js App Router
// 1. In a page or data fetcher (app/products/[id]/page.tsx)
async function getProduct(id: string) {
  const res = await fetch(`https://api.example.com/products/${id}`, {
    next: {
      tags: [`product-${id}`], // Tagged for on-demand revalidation
      revalidate: 3600,         // Fallback time-based ISR: 1 hour
    },
  });
  return res.json();
}

// 2. In a webhook route handler triggered by CMS / DB updates (app/api/revalidate/route.ts)
import { revalidateTag } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(req: NextRequest) {
  const { productId, secret } = await req.json();
  
  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid token' }, { status: 401 });
  }

  // Purge edge cache specifically for this product immediately!
  revalidateTag(`product-${productId}`);
  return NextResponse.json({ revalidated: true, now: Date.now() });
}

Interview-Ready Answers

CSR renders in browser via JS bundle. SSG renders HTML at build time (fastest, static). SSR renders HTML on every HTTP request (dynamic, personalized). ISR serves static HTML from CDN and revalidates in the background after a timeout.

Official Documentation & Specifications

Follow-up Questions & Deep Dives

Common Mistakes & Anti-Patterns

  • Using SSR for static pages, incurring unnecessary server CPU costs and higher TTFB
  • Relying on client-side useEffect fetching for public landing pages, damaging SEO and Core Web Vitals
  • Missing cache tags when using ISR, forcing developers to wait for arbitrary timeouts

Real-World Architectural Scenario

You are designing the Walmart product detail page (PDP) handling 100M daily page views. Prices change every few hours. How do you structure the rendering strategy?

Rate Your Readiness

Rate how comfortably you can explain this in an interview to update your global readiness gauge:

Rate your confidence: