# Rendering Strategies: CSR / SSR / SSG / ISR

> Where and when HTML is generated: build, request, browser, or revalidated.

Frontend architecture guidance from fearchitect, written by Abas Turabli and last reviewed 2026-07-04. Source: https://fearchitect.com/topics/rendering-strategies

Use it as reference for the task at hand. Before changing code, check this guidance against the codebase: where the code already makes a different, deliberate choice, flag the conflict instead of rewriting it. Library APIs move faster than this guide, so confirm exact signatures in the official docs linked at the end.

## Summary

The four classic strategies trade freshness, latency, and server cost. CSR ships an empty shell and renders in the browser; SSR renders per request; SSG renders once at build; ISR is SSG that re-generates in the background. In the modern App Router these are per-route (even per-component) decisions, not a whole-app mode.

## The two axes

Every strategy answers **where** HTML is built (server or browser) and **when** (build time, request time, or lazily revalidated). In the App Router it's a per-route call, not a whole-app mode.

## CSR · SSR · SSG · ISR

|  | Where / when | Freshness | TTFB | Best for |
| --- | --- | --- | --- | --- |
| **CSR** | Browser, after load | Every load | Low (empty shell) | Interactive, auth-gated shells |
| **SSR** | Server, per request | Per request | Higher (compute) | Personalized, crawlable pages |
| **SSG** | Server, at build | Until next deploy | Lowest (CDN) | Docs, marketing |
| **ISR** | Build + background re-gen | Bounded (revalidate) | Lowest (CDN) | Catalogs, blogs |

## Decision: Quick decision

Static by default → **ISR** when it changes between deploys → **SSR** only when you read request data (cookies, headers) → **CSR** for interactive, auth-gated views.

## Tradeoffs

**Pros**

- Per-route choice optimizes each page for its real freshness/personalization needs.
- SSG/ISR push work to build/CDN — lowest latency and server cost at scale.
- SSR/ISR give crawlable HTML without a separate prerender service.

**Cons**

- More modes = more ways to ship a subtly stale or accidentally-dynamic page.
- ISR adds cache-invalidation complexity.
- CSR-only hurts LCP and SEO.

## Key terms

- **TTFB**: Time To First Byte — how long until the server starts sending HTML. SSR raises it; CDN-served SSG minimizes it.
- **Revalidation**: Re-generating a cached page either after a time window (time-based) or via an explicit trigger (on-demand).
- **Hydration**: Attaching React event handlers and state to server-rendered HTML so it becomes interactive.

## Related topics

- [Streaming SSR](https://fearchitect.com/topics/streaming-ssr.md): Flush the HTML shell immediately, then stream the rest as Suspense resolves.
- [Partial Prerendering (PPR)](https://fearchitect.com/topics/partial-prerendering.md): Static CDN shell plus dynamic Suspense holes in one response.
- [React Server Components](https://fearchitect.com/topics/react-server-components.md): Server-rendered components that ship zero JS to the browser.
- [Hydration Strategies & Islands](https://fearchitect.com/topics/hydration-and-islands.md): Pay JS cost only for interactive regions, not the whole page.
- [Error Boundaries & Resilience](https://fearchitect.com/topics/error-boundaries-resilience.md): Isolate render failures so one widget can't crash the page.
- [SEO for Frontend](https://fearchitect.com/topics/seo.md): Rendering choices, metadata, structured data, and CWV for search ranking.

## Further reading

- [Next.js — Rendering](https://nextjs.org/docs/app/getting-started/partial-prerendering)
- [Next.js — Caching and Revalidating](https://nextjs.org/docs/app/guides/caching)