SSR vs SSG vs ISR: Pick the Right Render for Every Next.js Page

One of the most common architecture mistakes we see in Next.js projects: the team picks ONE rendering strategy for the entire app. Then the marketing pages pay for server renders they never needed, or the dashboard serves stale data it should never cache.

Next.js ships three rendering strategies. The right answer is per page, not per project. Here is the plain-English version.

SSR: Server-Side Rendering

HTML is built on the server on every request. The user always gets fresh HTML, personalized if needed.

Use it for: dashboards, shopping carts, anything with live or user-specific data.

Tradeoff: every visit costs server time, so it is slower (higher TTFB) and more expensive to scale than static options. SEO is excellent because crawlers get complete HTML.

SSG: Static Site Generation

HTML is built once, at build time, then served from a CDN to everyone.

Use it for: blogs, documentation, landing pages, marketing sites. Anything identical for every visitor that changes rarely.

Tradeoff: the fastest option with near-zero compute cost, but a content change means rebuilding the affected pages.

ISR: Incremental Static Regeneration

The hybrid. Pages are pre-rendered at build time like SSG, then regenerated in the background on a schedule you define, or on demand when you trigger it.

Use it for: product catalogs, news sections, CMS-driven pages. Content that changes periodically, where being a few minutes stale is acceptable.

Tradeoff: you get CDN speed without full rebuilds, in exchange for a small staleness window. In the App Router you control it with revalidate: N on a fetch call (or export const revalidate = N on the route), or trigger it instantly with revalidatePath() / revalidateTag(), for example from a CMS webhook.

The App Router defaults

In the modern App Router, SSG is the default: data fetches are cached unless you say otherwise. You opt into the other strategies deliberately: want ISR? Add revalidate: N. Want SSR? Use cache: 'no-store', or read cookies() / headers() / searchParams, which makes the route dynamic.

The decision rule

Forget the long comparison tables. Ask two questions about the page: 1. Does the data change on every request, or differ per user? Use SSR. 2. Is the page identical for every visitor? Use SSG. And the middle case: is 'fresh enough' (hourly, daily, on deploy) acceptable? Use ISR.

One framework, three gears. Mix them per page and you get an app that is fast where it can be static and fresh where it must be live, without paying for server renders you never needed.

Building with Next.js? We architect with the right render per page from day one. Let's talk: www.designstodeploy.dev