Next.js SSR vs SSG vs ISR: When to Use Each Rendering Mode
Next.js SSR vs SSG vs ISR: When to Use Each Rendering Mode - practical MillionsCode guide with key checks, related tools, examples, and FAQ.
Next.js SSR vs SSG vs ISR: When to Use Each Rendering Mode
Decision rule
SSR renders HTML for each request, so it fits dashboards, account pages, checkout states, inventory checks, and pages where cookies or permissions change the result.
SSG renders HTML during build, which makes it ideal for stable public pages such as documentation, help articles, landing pages, and evergreen tutorials.
ISR keeps the speed of static delivery while allowing a page to refresh after a chosen interval, so it works well for blogs, product pages, public rankings, and comparison guides.
The fastest decision test is cacheability: if the same HTML can safely be shown to many visitors, prefer SSG or ISR; if not, prefer SSR or client-side fetching for the private part.
Useful internal references: Next.js metadata, PageSpeed checker, meta tag checker, reading time calculator, image format guide.
Practical selection table
| Situation | Prefer | Reason |
|---|---|---|
| Stable public page | SSG | fastest delivery and simple cache |
| Public content with occasional updates | ISR | static speed plus controlled refresh |
| User-specific page | SSR | request data and permissions matter |
| Real-time widget | SSR or client fetch | freshness matters more than build speed |
Operating checklist
Check whether the HTML can be cached, how often the source data changes, whether build time grows with content count, and whether SEO metadata is available in the first response. Also check images, fonts and third-party scripts because they can damage performance even when the rendering mode is correct.
FAQ
Is SSR always better for SEO?
No. SSG and ISR also deliver complete HTML, and they are often faster for public content.
What is the safest default?
Use SSG for stable pages, ISR for public pages that change sometimes, and SSR for request-specific pages.
Extra field notes
SSR renders HTML for each request, so it fits dashboards, account pages, checkout states, inventory checks, and pages where cookies or permissions change the result. SSG renders HTML during build, which makes it ideal for stable public pages such as documentation, help articles, landing pages, and evergreen tutorials. ISR keeps the speed of static delivery while allowing a page to refresh after a chosen interval, so it works well for blogs, product pages, public rankings, and comparison guides. The fastest decision test is cacheability: if the same HTML can safely be shown to many visitors, prefer SSG or ISR; if not, prefer SSR or client-side fetching for the private part. The team should document this decision per route, measure cache hit rate, and revisit the choice when content volume, update frequency, or personalization changes. Rendering strategy is a per-page decision, not a one-time project rule.