SSR vs CSR vs Static Generation

Interview Question: "When would you choose SSR over CSR? What about static generation? Walk me through the trade-offs."

The Senior Answer

Don't start with definitions. Start with the decision framework:

"The choice depends on four factors: data freshness, SEO requirements, interactivity needs, and infrastructure budget. There's no universally correct answer — modern apps mix strategies per route."

The Quick Mental Model

Who generates the HTML?
 
  Build server (ahead of time)  →  Static Generation (SSG/ISR)
  Web server (per request)      →  Server-Side Rendering (SSR)
  User's browser (at runtime)   →  Client-Side Rendering (CSR)

CSR (Client-Side Rendering)

"The server sends an empty HTML shell with a JavaScript bundle. The browser downloads, parses, and executes JS, then makes API calls and renders the page. The user sees nothing meaningful until JS finishes — which can be 3-5 seconds on mobile."

Choose when: App is behind authentication, highly interactive (dashboards, editors), no SEO needed, simple static hosting preferred.

Avoid when: SEO matters, first-load performance is critical, targeting low-end devices.

SSR (Server-Side Rendering)

"The server fetches data and renders complete HTML per request. The user sees content immediately. Then JS hydrates the page for interactivity. The gap between 'I see content' and 'I can interact' is the hydration cost."

Choose when: SEO required, personalized content per request, first-paint speed matters.

Avoid when: Content rarely changes (SSG is cheaper), server costs are a concern, page is pure interaction.

SSG (Static Site Generation)

"Pages are pre-built at deploy time. Served from CDN edge — the fastest possible delivery. But content is frozen at build time."

Choose when: Content changes infrequently (docs, blogs, marketing pages), maximum performance needed.

Avoid when: Content updates frequently, pages need personalization, you have millions of pages (build time explodes).

ISR (Incremental Static Regeneration)

"The best of SSG and SSR — pages are statically served from cache but regenerate in the background on a configurable interval. Users always get fast responses; data staleness is bounded."

Streaming SSR

"Instead of waiting for all data before sending HTML, the server streams content progressively using Suspense boundaries. The shell and navigation arrive instantly, and each data section fills in as its API call resolves."

The Comparison Table

Follow-Up Questions

"What is hydration and why is it a problem?"

"Hydration is the process where React attaches event handlers to server-rendered HTML. The problem is the 'uncanny valley' — the page looks interactive (buttons visible, text readable) but nothing works until JS loads and hydrates. Users click buttons that don't respond.

Modern solutions: Streaming SSR with selective hydration (React 18), React Server Components (zero-JS for non-interactive parts), and Islands architecture (only hydrate interactive components)."

"How do you choose per route?"

"I map each route to the strategy that fits:

• Landing page → SSG (maximum speed, no dynamic data)
• Product listing → ISR (data changes hourly, SEO critical)
• Product detail → SSR with streaming (personalized pricing, SEO critical)
• Dashboard → CSR or Streaming SSR (behind auth, real-time data)
• Settings → CSR (no SEO, fully interactive)"

"Where do React Server Components fit?"

"RSC is orthogonal to SSR vs CSR. Server Components reduce the client JavaScript bundle — non-interactive components never ship JS to the browser. They compose with any rendering strategy. In Next.js App Router, pages are Server Components by default with 'use client' boundaries for interactivity."

The One-Liner

"SSG is the fastest delivery for known content. SSR is the right answer when content depends on the request. CSR is the right answer when nothing matters until the user is authenticated. The real skill is mixing them in the same application."

Red Flags

• Saying "SSR is always better" without discussing server cost and TTFB
• Not mentioning hydration as a trade-off of SSR
• Ignoring ISR and Streaming as modern alternatives
• Treating it as a binary choice instead of a per-route decision
• Not connecting strategies to metrics (FCP, LCP, TTI)