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 stale can the page get before it's wrong?
Does each visitor see something different?
Does it need crawlable HTML and a fast first paint?
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 callA 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.
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.