What you'll learn
- Pick the mode from freshness, personalization, and SEO needs
- SSG/ISR for mostly public content; SSR for per-request data
- CSR for highly interactive authenticated shells
- Link to the deeper rendering guide for mechanics
Direct answer: use SSG when content is the same for everyone and can wait for a build or regenerate. Use ISR when it is mostly static but must refresh on a timer or on demand. Use SSR when HTML must reflect per-request data. Use CSR when the experience is app-like after load and SEO for that view is not the goal.
Mechanics and diagrams: React Rendering Strategies. Freshness without full rebuilds: Update Content Without Redeploying.
When to use each
| Mode | Use when |
|---|---|
| SSG | Docs, marketing, handbook pages that change with deploys |
| ISR | Same as SSG but editors need faster updates |
| SSR | Personalized or highly request-specific HTML |
| CSR | Authenticated dashboards where SEO of the shell is optional |
When not to use
- Do not SSR everything “for SEO” if the page is behind login
- Do not CSR public marketing pages if you need reliable first HTML for search and social
- Do not ISR if every visitor must see a different private payload (use SSR or client fetch after auth)
Practical framing
Public article, edits weekly -> SSG or ISR
Product landing, rare edits -> SSG
Per-user inbox HTML -> SSR or CSR after shell
Admin dashboard -> CSR (often) with auth gateCommon mistakes
- Mixing stale CDN HTML with client fetches and calling it “SSR”
- Forgetting revalidation after CMS publish (see the content-update guide)
- Choosing CSR first, then fighting SEO later
Checklist
- Is the HTML public and shareable? Prefer SSG/ISR/SSR over pure CSR.
- Does content change without a full rebuild often? Prefer ISR or SSR.
- Is data per user and private? CSR or SSR with auth, not a public SSG page.
- Did you confirm the mode in production headers/cache behavior?
Related
Final recommendation
Start from product constraints (public vs private, freshness, SEO), then pick the lightest mode that meets them. Prefer static HTML for public content; add request-time work only when the data forces it.