May 20, 2026 · 7 min read
SSR vs SSG vs ISR and React Server Components: a practical Next.js guide
A practical guide to choosing between SSR, SSG, ISR, and React Server Components when building fast, maintainable Next.js applications.
Choosing a rendering strategy is one of the earliest architecture decisions in a Next.js project. It affects performance, infrastructure cost, caching behavior, user experience, and how easily the product can evolve.
The important part is not memorizing acronyms. The important part is matching the page to the shape of the data: how often it changes, whether it is personalized, and how painful stale content would be.
This guide breaks down SSG, ISR, SSR, and React Server Components from a production architecture point of view.
Start with the data, not the framework feature
Before choosing SSR, SSG, or ISR, ask three questions about the route you are building.
Is the content the same for every visitor? How quickly must updates appear? Does the page depend on private user state, authentication, or request-time permissions?
- If the content is public and rarely changes, generate it statically.
- If the content is public but changes regularly, use background regeneration.
- If the content is private, personalized, or permission-sensitive, render it at request time.
- If only a small part of the page is interactive, keep the page mostly server-rendered and isolate the interactive pieces.
The quick comparison
This is the high-level trade-off matrix. It is intentionally simple because most rendering decisions should be simple at first.
| Strategy | When HTML is created | Best for | Speed | Data freshness |
|---|---|---|---|---|
| SSG | Build time, once | Blogs, documentation, landing pages | Fastest | Stale until rebuild |
| ISR | Build time, then regenerated in the background | Ecommerce catalogs, CMS pages, pricing pages | Fast | Delayed updates |
| SSR | Runtime, on every request | Dashboards, account pages, authenticated routes | Slower | Real-time |
SSG: static pages that should be almost instant
Static Site Generation creates the HTML at build time. After deployment, the page can be served directly from a CDN with very little runtime work.
This is the best default for public content that does not need request-time personalization.
- Use it for marketing pages, documentation, changelog entries, public blog posts, and stable product pages.
- The upside is excellent latency, low server cost, and very predictable caching.
- The trade-off is freshness: changing the content usually requires a rebuild and redeploy.
- Avoid it for user-specific pages, shopping carts, account settings, or anything that depends on private request data.
ISR: static speed with controlled freshness
Incremental Static Regeneration keeps the static delivery model but allows pages to be refreshed after deployment. A page can be generated once, served quickly, and then updated in the background according to a revalidation policy.
This is often the right fit for public pages where content changes matter, but not to the exact second.
- Use it for ecommerce product pages, category pages, CMS-driven articles, documentation synced from external systems, and pricing pages where a short freshness window is acceptable.
- The upside is near-static speed without rebuilding the entire site for every content change.
- The trade-off is that a visitor may briefly see the previous version while regeneration happens.
- Be explicit about stale content tolerance before choosing the revalidation interval.
SSR: request-time rendering for dynamic and private pages
Server-Side Rendering creates the HTML for each request. That makes it a better fit when the response depends on the current user, cookies, headers, permissions, location, or live backend state.
SSR is powerful, but it should be used intentionally because every request creates server work.
- Use it for dashboards, authenticated pages, account settings, admin tools, checkout flows, and pages with strict freshness requirements.
- The upside is fresh, permission-aware content with backend logic kept off the client.
- The trade-off is higher server load and typically slower Time to First Byte than CDN-served static pages.
- Protect SSR routes with caching, streaming, query optimization, and clear loading boundaries.
React Server Components change where work happens
React Server Components are a separate architectural decision from SSR, SSG, and ISR. Rendering strategy decides when the route output is created. Server Components decide where component work runs and what JavaScript reaches the browser.
A Server Component executes on the server and is never shipped as client-side JavaScript. That means it can fetch data directly, use server-only dependencies, and keep sensitive logic away from the browser bundle.
- Server Components are ideal for data fetching, layout composition, markdown rendering, database reads, and preparing view models.
- They reduce client-side waterfalls because data can be fetched during server rendering instead of inside
useEffectafter hydration. - They can keep heavy packages such as markdown parsers, date utilities, and data clients out of the client bundle.
- They cannot use
useState,useEffect, browser APIs, or event handlers such asonClick.
Use Client Components as small interactive islands
The healthiest pattern in modern Next.js is to keep components server-first and add Client Components only where interactivity is actually needed.
That usually means the route, data loading, and most layout stay on the server. Buttons, forms, filters, menus, charts, and animated controls become focused Client Components at the edges.
- Fetch data in a Server Component, then pass serializable data into a Client Component.
- Keep
use clientfiles small and close to the interaction they enable. - Do not move an entire page to the client just because one widget needs state.
- Treat client-side JavaScript as a budget, not a default.
A practical decision model
For most product routes, the decision can be reduced to a few rules.
- Use SSG when the same public HTML works for everyone and updates are rare.
- Use ISR when the same public HTML works for everyone but content changes on a schedule or from a CMS.
- Use SSR when the response must be personalized, permission-aware, or fresh at request time.
- Use Server Components by default for data access and non-interactive UI.
- Use Client Components only for browser-only behavior and direct user interaction.
Final take
The goal is not to pick the most advanced option. The goal is to keep static pages static, dynamic pages accurate, server work on the server, and client JavaScript limited to the parts of the interface that genuinely need it.