Static, ISR, SSR, CSR — the spectrum
Web pages live somewhere on a line from "fully static, served from a CDN" to "fully dynamic, rendered per request in JavaScript on the client." Next.js supports the entire spectrum and lets you pick per route or per fetch.
| Strategy | When it's chosen | Use cases |
|---|---|---|
| SSG (build time) | No request-time data, fetches are cached | Docs, blog posts, marketing pages |
| ISR (revalidate) | Static + a revalidate hint | Product pages, news feed, pricing |
| SSR (per request) | Reads cookies(), headers(), searchParams | Auth'd pages, dashboards, search |
| CSR (browser) | Inside a Client Component using state | Live editors, collaborative UI |
How Next.js detects which mode you're in
You don't pick a mode by name — you pick it by the APIs you call. Use cookies() or headers() and the route becomes dynamic. Mark a fetch with cache: 'force-cache' and that data point is static. The detection is automatic at build time.
Why this matters before you write a line
Picking the wrong point on the spectrum is how Next.js apps end up either expensive (everything dynamic) or stale (everything static). Decide per route: what changes, how often, who pays the freshness cost.