Explain SSR vs SSG vs CSR, and how does each affect AI-generated content rendering

CSR renders in the browser (good for dynamic/personalized, bad for first paint/SEO). SSR renders per request on the server (fresh, SEO-friendly, slower TTFB). SSG pre-renders at build time (fastest, cacheable, stale). AI content is dynamic and slow — usually CSR/streaming SSR, not SSG.

7 min read·~12 min to think through

Three rendering strategies, differing in where and when HTML is produced.

CSR — Client-Side Rendering

The server sends a near-empty HTML shell + a JS bundle; the browser runs JS to render everything.

✅ Rich interactivity, cheap to host (static files), great for personalized/dynamic UIs behind auth.
❌ Slow first paint (download + parse + execute JS first), weaker SEO (crawlers see the empty shell unless they execute JS), blank screen on slow devices.

SSR — Server-Side Rendering

The server renders the full HTML for each request, browser hydrates it.

✅ Fast meaningful first paint, SEO-friendly (real HTML), always fresh, good for dynamic + crawlable pages.
❌ Higher TTFB (server work per request), needs a running server, more infra cost.

SSG — Static Site Generation

HTML is pre-rendered at build time; served as static files (via CDN).

✅ Fastest possible delivery, ultra-cheap, CDN-cacheable, SEO-friendly.
❌ Content is fixed until the next build — stale for anything dynamic; build time grows with page count. (ISR — incremental static regeneration — softens this by re-generating pages on a schedule/on-demand.)

	CSR	SSR	SSG
Renders	in browser	server, per request	server, at build
First paint	slow	fast	fastest
SEO	weak	strong	strong
Freshness	live	per-request fresh	build-time stale
Best for	dynamic, personalized, auth'd apps	dynamic + SEO pages	mostly-static content

Modern frameworks mix these per route (Next.js App Router, Remix) — and add React Server Components and streaming SSR.

How this affects AI-generated content

AI content has two defining traits: it's dynamic/personalized (depends on a prompt, often a user) and slow (seconds to generate). That rules things in and out:

SSG is usually wrong for AI content — you can't pre-render at build time what depends on a runtime prompt. Exception: a fixed set of AI-generated pages (e.g. AI-written articles) generated once at build → then SSG/ISR is great and cacheable.
CSR is the natural fit for interactive AI (chat, assistants) — generation happens after user input anyway, so render the shell instantly and stream the AI response into it client-side. The slow part is the AI call, not rendering.
SSR / streaming SSR works when AI content must be in the initial HTML (SEO, sharing) — but blocking SSR on a multi-second AI call kills TTFB. So use streaming SSR: send the shell immediately, stream the AI-generated chunk into the HTML as it's produced (React 18 streaming + Suspense). Best of both — fast shell + server-rendered AI content.
Caching matters — AI calls are expensive and slow; cache generated responses (by prompt hash) regardless of strategy. ISR is a way to cache AI-generated pages.

Rule of thumb: interactive AI → CSR + streaming. AI content needing SEO → streaming SSR. A fixed corpus of AI-generated pages → SSG/ISR with caching. Never block a build (SSG) or a request (blocking SSR) on a live AI generation.

How to answer

Define the three by where/when HTML is produced and their tradeoffs, then connect: AI content is dynamic + slow, so SSG generally doesn't fit (can't pre-render prompt-dependent content); interactive AI suits CSR with streaming; AI content needing SEO suits streaming SSR so the shell isn't blocked on the slow generation; and cache AI outputs because they're expensive.

Follow-up questions

•Why is SSG usually a poor fit for AI-generated content?
•How does streaming SSR avoid blocking TTFB on a slow AI call?
•When would SSG/ISR actually work for AI content?
•How do React Server Components fit into this?

Common mistakes

•Blocking an SSR response on a multi-second AI generation, killing TTFB.
•Trying to SSG content that depends on a runtime prompt.
•Not caching expensive AI responses.
•Treating the three strategies as mutually exclusive instead of per-route.
•Ignoring streaming as the bridge for slow dynamic content.

Performance considerations

•Streaming SSR sends the shell fast and fills AI content as it generates — avoids the TTFB hit of blocking SSR. CSR + streaming keeps the app instant and lets the slow AI call resolve progressively. Caching AI outputs by prompt hash is the biggest cost/latency win.

Edge cases

•A fixed corpus of AI-generated articles (SSG/ISR works).
•AI content that must be crawlable and shareable (streaming SSR).
•Hydration mismatches with nondeterministic AI output.
•Personalized AI content that can't be cached across users.

Real-world examples

•A chat app: CSR shell + client-streamed AI responses.
•An AI-generated article site: SSG/ISR with pages generated at build, cached on a CDN.
•Streaming SSR filling an AI summary into otherwise static page HTML.

Senior engineer discussion

Seniors define the three by where/when HTML is produced, note modern frameworks mix them per route, then reason from AI content's traits (dynamic + slow) to the right fit: CSR+streaming for interactive AI, streaming SSR when SEO is needed (never blocking SSR), SSG/ISR only for a fixed AI-generated corpus — plus caching outputs because AI calls are expensive.