LearnAI ToolsCareerPractice BuildsPlayContact
Lesson 2520 min read

Rendering Strategies (SSR, SSG, ISR, CSR)

A complete map of the four rendering strategies Next.js offers, and how to reason about which one a route is using.

Four Ways to Render a Page

Every page needs its HTML generated somewhere and at some point in time. Next.js supports four distinct strategies, and — uniquely — lets you choose per route rather than locking your whole app into one.

SSG — Static Site Generation

HTML is generated once, at build time. Served instantly from a CDN to every visitor.

SSR — Server-Side Rendering

HTML is generated fresh, on the server, for every single request.

ISR — Incremental Static Regeneration

Like SSG, but pages automatically regenerate in the background after a set time interval.

CSR — Client-Side Rendering

HTML is minimal at first; data fetches and rendering happen in the browser.

Comparison Table

StrategyWhen HTML Is BuiltData FreshnessBest For
SSGAt build timeFixed until next buildMarketing pages, docs, blogs
SSROn every requestAlways freshPersonalized or highly dynamic pages
ISRAt build, then periodicallyFresh within a set intervalProduct pages, news — content that changes but not per-request
CSRIn the browser, after loadFresh at fetch timeBehind-login dashboards, highly interactive tools

How Next.js Decides

In the App Router, the strategy for a route is inferred from how you fetch data and which APIs you use, rather than a separate config file per page.

  • A page with no dynamic data access is statically rendered (SSG) by default.
  • Using fetch with { cache: "no-store" }, or reading cookies/headers, makes a route dynamically rendered (SSR) at request time.
  • Adding a revalidate value to a fetch (or route segment) turns static rendering into ISR.
  • A page that's entirely a Client Component fetching in useEffect behaves like CSR for that data.
One Route, Any Strategy

Because the strategy comes from how you write the route, not a project-wide switch, one Next.js app can have static marketing pages, SSR account pages, and ISR product pages, all side by side.

Choosing a Strategy

Does the content need to be personalized per user?
↓
Yes → Use SSR (or CSR behind auth)
↓
No — does the content change often but not per request?
↓
Yes → Use ISR with a revalidate interval
↓
No — is the content essentially fixed?
↓
Yes → Use SSG

FAQs

A page has one overall rendering mode, but you can combine it with client-side fetching for specific interactive widgets inside an otherwise static page.

For the same content, yes — SSG serves pre-built HTML instantly, while SSR does work on every request. SSR is worth that cost only when the content genuinely must be fresh or personalized.

Summary

Next.js lets you pick the right rendering strategy per route based on how fresh the data needs to be. The next three lessons go deep on SSG, SSR, and ISR individually, starting with Static Site Generation.

Next Lesson →

Static Site Generation