SSR vs SSG vs ISR: When to Use Each Rendering Strategy

SSR vs SSG vs ISR is one of the most confusing decisions in modern web development. The choice affects page load speed, server cost, content freshness, and SEO outcomes — and most teams make the choice based on default templates rather than first principles.

This guide is the decision framework we use on every client build. It covers what Server-Side Rendering, Static Site Generation, and Incremental Static Regeneration actually do, when each one is the right tool, and the trade-offs that determine real-world performance and cost.

The framework applies to Next.js, but the underlying decisions are framework-agnostic. The same trade-offs exist in Astro, SvelteKit, Nuxt, and Remix.

What each rendering strategy actually does

The three strategies differ in when the HTML is generated and how it is delivered.

Static Site Generation (SSG)

HTML is generated at build time. Every page is pre-rendered once, then served as a static file.

Result: fastest possible delivery, zero server compute at request time, full CDN caching.

Server-Side Rendering (SSR)

HTML is generated on every request. The server runs the component tree, fetches data, and returns fresh HTML.

Result: always-fresh content, personalisation possible, higher server cost, slower delivery.

Incremental Static Regeneration (ISR)

HTML is generated at build time (like SSG) but revalidated on a schedule. After the revalidation window expires, the next request triggers a regeneration in the background, then serves fresh HTML to subsequent visitors.

Result: nearly-as-fast as SSG, content freshens on a cadence, low server cost, predictable performance.

We covered the broader Next.js performance picture in our Next.js performance best practices guide. Rendering strategy is one of the highest-leverage decisions you make.

The decision matrix

For each page type, ask three questions.

How often does the content change?

• Never (within a deploy cycle): SSG
• Daily to hourly: ISR
• Per-request (real-time): SSR

Does the content vary per user?

• No (same for everyone): SSG or ISR
• Yes (personalised, authenticated): SSR or client-side fetch

What is the traffic pattern?

• High traffic on stable content: SSG or ISR (cache aggressively)
• Low traffic on dynamic content: SSR is fine
• High traffic on dynamic content: SSR with caching or move to ISR

Apply these three filters and the right strategy usually becomes obvious.

When to use SSG

SSG is the gold standard for content that does not change per request.

Ideal use cases

• Marketing pages (homepage, services, about, contact)
• Blog posts with stable content
• Documentation
• Landing pages for paid campaigns
• Course catalogs that change infrequently
• Portfolio sites

Why SSG wins for these cases

• Fastest delivery: HTML is pre-built, served from CDN edge, no server compute
• Free CDN distribution
• Zero scaling concerns (static files scale infinitely)
• Lowest hosting cost
• Best Core Web Vitals out of the box

Trade-offs

• Content updates require redeploy (or ISR)
• Build times grow with page count
• No real-time personalisation
• Large sites with thousands of pages can take 10+ minute builds

When SSG breaks

Sites with 100,000+ pages can hit build-time limits. For these, ISR or on-demand generation becomes necessary.

For most SME sites, SSG works for 80+ percent of pages. The remaining 20 percent need other strategies.

When to use SSR

SSR is the right choice when content must be fresh on every request or varies per user.

Ideal use cases

• Authenticated dashboards
• Personalised feeds
• Real-time analytics views
• E-commerce cart and checkout pages
• Account settings
• Any page where data changes second-to-second

Why SSR wins for these cases

• Always-fresh data
• Per-user personalisation server-side
• No client-side flash of stale content
• SEO-friendly (search engines see the full content)

Trade-offs

• Higher TTFB (server must compute the page)
• Higher hosting cost (every request runs server code)
• Cannot be CDN-cached the same way as static content
• Scaling requires more infrastructure

Reducing SSR cost

Even SSR pages can use caching:

• Cache database queries (Redis, Vercel KV)
• Cache rendered components (React Server Components support this natively)
• Use unstable_cache in Next.js for memoizable computations
• Stream the response (React Suspense in Next.js App Router)

We covered the caching layer in our caching strategies for web performance guide.

When to use ISR

ISR is the sweet spot for content that changes occasionally but does not need per-request freshness.

Ideal use cases

• E-commerce product pages (price, inventory updates a few times a day)
• News and blog sites with frequent posts
• Catalog and listing pages
• Public portfolios that update weekly
• Documentation that updates on a schedule

Why ISR wins for these cases

• Near-SSG speed (cached static HTML served from CDN)
• Content freshens automatically on schedule
• No build-time bottleneck (pages can generate on demand)
• Lower cost than SSR
• Better Core Web Vitals than SSR

How ISR works in Next.js App Router

export const revalidate = 3600; // revalidate every hour

export default async function ProductPage({ params }) {
  const product = await fetch(`/api/products/${params.slug}`).then(r => r.json());
  return <ProductDetail product={product} />;
}

The page is generated, cached, and served as static for 1 hour. After 1 hour, the next request triggers background regeneration. Visitors during regeneration see the cached (slightly stale) version. Subsequent visitors get the fresh version.

On-demand revalidation

For content that needs to update immediately (after a CMS publish, for example), use on-demand revalidation:

import { revalidatePath, revalidateTag } from "next/cache";

// In an API route triggered by CMS webhook
revalidatePath("/blog/[slug]");
revalidateTag("product");

This invalidates the cache immediately. Next request gets fresh content.

ISR trade-offs

• Some users will see slightly-stale content during the revalidation window
• More complex mental model than pure SSG or SSR
• Build pipeline must be aware of ISR routes

For most non-real-time use cases, the trade-offs are worth the performance and cost savings.

A real-world site architecture

Most production sites use a mix of strategies. Here's how a typical e-commerce site is structured.

SSG pages

• Homepage
• Category landing pages (refreshed weekly via redeploy)
• About, contact, FAQ
• Blog posts (updated weekly)

ISR pages

• Product detail pages (revalidate every 1 hour)
• Category list pages with product cards (revalidate every 1 hour)
• Author pages
• Press pages

SSR pages

• Cart and checkout
• Account dashboard
• Order history
• Real-time search results

Client-side only

• Live chat
• Real-time notifications
• Interactive product configurators

The mix matches each page's actual requirements rather than applying one strategy across the site.

Performance comparison

In practice, the speed ranking is:

1. SSG: fastest. Pure static file from CDN edge.
2. ISR: nearly as fast. Static file from cache, occasional regeneration.
3. SSR: slower. Server compute on every request.

Real-world TTFB numbers from a typical Vercel deployment:

• SSG: 30 to 80 ms
• ISR (cache hit): 30 to 80 ms
• ISR (cache miss, regenerating): 200 to 800 ms
• SSR: 300 to 1,500 ms depending on data dependencies

The difference compounds into LCP and conversion impact. We covered the LCP impact in our Core Web Vitals deep dive guide.

Cost comparison

For a hypothetical site with 1 million monthly page views:

• SSG: $0 to $20/month (just CDN bandwidth on Vercel)
• ISR: $20 to $100/month (CDN + occasional server compute)
• SSR: $200 to $2,000/month (compute on every request)

For high-traffic sites, the cost difference between SSR and ISR/SSG can be substantial. Optimising rendering strategy is often the largest single hosting cost reduction.

Common rendering strategy mistakes

These are the patterns we see most often.

SSR everything because it feels safer. Most pages do not need request-time freshness. SSG or ISR work better.

SSG everything when content changes. Stale content frustrates users. ISR is the right middle ground.

ISR with revalidate too short. A 60-second revalidate on a 1 million-view site triggers regeneration constantly. Set the revalidate window to match actual update frequency.

SSR without caching. SSR pages can still cache database queries and computed values. Without caching, SSR is slow and expensive.

Client-side fetching when server fetching would work. Adds a network round-trip after page load. Server-side fetching is faster and SEO-friendly.

Mixed strategies without clear rationale. Each page should have a defendable reason for its rendering strategy.

Migration patterns

When refactoring an existing site, common migration paths:

From SSR-everywhere to mixed strategy

1. Identify pages that do not need request-time freshness
2. Convert them to SSG or ISR
3. Measure cost reduction
4. Verify content freshness expectations

This is the most common refactor. Most SSR-everywhere apps can move 60 to 80 percent of pages to faster strategies.

From SSG-everywhere to ISR for dynamic content

1. Identify pages that should update more frequently than your deploy cadence
2. Convert to ISR with appropriate revalidate windows
3. Set up on-demand revalidation for content-change events

Useful for blog and catalog sites that have outgrown weekly deploys.

From legacy WordPress to Next.js

1. Map current page types
2. Decide rendering strategy per type
3. Set up content sourcing (headless CMS, file-based, or direct database)

We've done this migration on several client sites. The performance and SEO improvements are typically substantial.

A real example — Dubai SaaS architecture

A Dubai-based B2B SaaS we work with originally used SSR for every page including marketing pages. Costs were $1,800/month on Vercel for moderate traffic.

After refactoring:

• Marketing pages → SSG (no change needed, redeploy on content update)
• Pricing page → ISR with 1-hour revalidate (prices change occasionally)
• Documentation → ISR with on-demand revalidation (CMS-triggered)
• Authenticated dashboard → SSR (must be fresh and personalised)
• Marketing blog → SSG

Result: hosting cost dropped to $280/month. LCP on marketing pages improved from 1.8 seconds to 0.6 seconds. The full story is in our Dubai SaaS case study.

Frequently asked questions

Is SSG always better than SSR?

For content that does not change per request, yes. SSG is faster and cheaper. SSR is necessary for personalised or real-time content.

Does ISR have any downsides?

The main trade-off is that some users see slightly-stale content during the revalidation window. For most use cases this is acceptable.

Can I mix SSG and SSR in the same app?

Yes. Next.js, Astro, Nuxt, SvelteKit, and Remix all support per-page strategy selection. Most production apps mix all three.

Should authenticated pages be SSR?

Usually yes. Authentication state must be checked server-side to avoid flash of unauthenticated content and to keep SEO-irrelevant pages out of search index.

How do I decide the revalidate window for ISR?

Match it to actual update frequency. If content changes hourly, revalidate hourly. If daily, revalidate daily. Shorter windows cost more server compute.

Can SSG work with personalised content?

Not directly. For personalised content, use SSG for the static shell and load personalised content client-side after page load.

Get a rendering strategy audit

We audit rendering strategies free of charge. Within 48 hours we deliver a per-page-type analysis with recommendations and expected cost and performance impact.

Book a free 30-minute audit. We screen-share, walk through your site architecture and traffic patterns, and you leave with a clear strategy.

Or explore our Web Development service for the full system we run on performance-focused client accounts.