How does the Rendering Strategy Picker choose between SSG, ISR, SSR and CSR?

It runs your answers to four questions, about freshness, personalization, SEO and scale, through a decision tree. Per-user or per-request needs point to SSR or CSR, while shareable cacheable content points to SSG for static data or ISR for content that refreshes on a schedule.

Does it give me actual Next.js config?

Yes. For each recommendation it outputs an App Router snippet, such as export const revalidate equals 3600 for a one-hour ISR window, along with the reasons it fits, the gotchas to watch, and a runner-up strategy.

Should I pick one strategy for my whole app?

No. Real apps mix strategies per route: a static marketing page, an ISR catalog, an SSR dashboard, a CSR settings panel. Run each meaningful route through the picker rather than choosing one strategy for everything.

Are the revalidation windows exact recommendations?

No. The windows are heuristics. Your real staleness tolerance depends on the page, so adjust the window to what your content can accept.

Does the tool send my answers anywhere?

No. The decision logic runs in your browser and nothing is transmitted. Your selections are only encoded into the URL when you copy a shareable link.

free_tool

Rendering Strategy Picker

SSG, ISR, SSR or CSR? The right answer is a property of the page, not a preference. Answer four questions about freshness, personalization, SEO and scale, and get the rendering strategy that fits, with the Next.js App Router config to ship it and the trade-offs to watch.

How fresh must the data be?

How stale can the page get before it's wrong?

Is the page personalized?

Does each visitor see something different?

How much does SEO / first paint matter?

Does it need crawlable HTML and a fast first paint?

What's the traffic / scale?

How much load hits this page?

Recommended strategy

ISRrevalidate 3600s

Incremental Static Regeneration

Serve static, refresh in the background on a schedule.

// Static HTML, regenerated in the background every 1h
export const revalidate = 3600;
// Push updates instantly with on-demand revalidation:
//   revalidatePath('/path')  ·  revalidateTag('tag')

Why this fits

Data changes on the order of minutes to hours, so a short staleness window is acceptable.
ISR serves cached static HTML and regenerates in the background, so you get static-level speed with periodic freshness.
Crawlers and users both get instant, fully rendered HTML.

Watch out

Visitors can see data up to 1h stale, so use on-demand revalidation for changes that must show immediately.
The first request after the window serves stale while it regenerates; tune revalidate to your tolerance.

Runner-up · SSG
If the data is effectively fixed, plain SSG drops the regeneration entirely.

SSG: Prerender once at build, serve from the CDN.
ISR: Serve static, refresh in the background on a schedule.
SSR: Render fresh HTML on every request.
CSR: Ship a cacheable shell, fetch data in the browser.

Mixed signals across pages, or a rendering choice that's quietly costing you on speed or bill? I'll map each route to the right strategy.

Get your rendering reviewed: book a call

A guide for the common cases, not a replacement for judgement. Real apps mix strategies per route: a static marketing page, an ISR catalog, an SSR dashboard, a CSR settings panel, and that's exactly right. Run each meaningful route through it.

the_four_options

Four ways to render, one question each

The whole decision comes down to when the HTML is built and who it can be shared with. Build it once at deploy and you get the fastest, cheapest page. Build it per request and you get freshness and personalization, at a cost. Everything else is a point on that line.

SSG: Prerender once at build, serve from the CDN.
ISR: Serve static, refresh in the background on a schedule.
SSR: Render fresh HTML on every request.
CSR: Ship a cacheable shell, fetch data in the browser.

See how I can help →

faq

Questions & answers

How does the Rendering Strategy Picker choose between SSG, ISR, SSR and CSR?: It runs your answers to four questions, about freshness, personalization, SEO and scale, through a decision tree. Per-user or per-request needs point to SSR or CSR, while shareable cacheable content points to SSG for static data or ISR for content that refreshes on a schedule.
Does it give me actual Next.js config?: Yes. For each recommendation it outputs an App Router snippet, such as export const revalidate equals 3600 for a one-hour ISR window, along with the reasons it fits, the gotchas to watch, and a runner-up strategy.
Should I pick one strategy for my whole app?: No. Real apps mix strategies per route: a static marketing page, an ISR catalog, an SSR dashboard, a CSR settings panel. Run each meaningful route through the picker rather than choosing one strategy for everything.
Are the revalidation windows exact recommendations?: No. The windows are heuristics. Your real staleness tolerance depends on the page, so adjust the window to what your content can accept.
Does the tool send my answers anywhere?: No. The decision logic runs in your browser and nothing is transmitted. Your selections are only encoded into the URL when you copy a shareable link.

Rendering choices feeling ad hoc?

I'll map each route to the right strategy, and untangle the slow SSR pages, the over-eager ISR, and the CSR that's tanking your SEO. Book a call, or leave your email.

Book a call

Prefer proof first? See how this plays out in real case studies →