Jay Poojara
BACK TO BLOG

SSR vs SSG vs ISR in Next.js — When to Use What (With Real Examples)

next.jsssrssgisrreactperformanceseorendering-strategiesweb-development

Every Next.js project hits the same crossroads: should this page be server-rendered on every request (SSR), pre-built at deploy time (SSG), or statically generated and then refreshed in the background (ISR)? Pick wrong, and you pay with slow Time to First Byte, stale content, or unnecessary infrastructure cost.

After shipping Next.js apps for Breville, CAFU, Rabbit Care, and Eyewa — each with very different traffic patterns, content freshness needs, and SEO requirements — I've landed on a repeatable decision framework. This post walks through it with real examples, a flowchart, and the gotchas nobody mentions until you hit them in production.

Quick Refresher: SSR, SSG, and ISR in Next.js

Static Site Generation (SSG)

Pages are pre-rendered at build time. The HTML is generated once, cached on the CDN, and served instantly to every visitor. This is the fastest rendering strategy in Next.js because there is zero server computation at request time. It's ideal for content that rarely changes — marketing pages, documentation, blog posts, and landing pages.

In the App Router, any page that doesn't opt into dynamic behavior is statically generated by default. In the Pages Router, you'd export getStaticProps. The trade-off is simple: you get blazing-fast TTFB and perfect Lighthouse scores, but content only updates when you redeploy.

Server-Side Rendering (SSR)

Pages are rendered on the server for every incoming request. The HTML is freshly generated each time, so the user always sees the latest data. SSR is essential when the page depends on request-specific information — cookies, authentication headers, geolocation, or real-time pricing.

In the App Router, you trigger SSR by using dynamic functions like cookies(), headers(), or searchParams, or by setting export const dynamic = "force-dynamic". In the Pages Router, you'd export getServerSideProps. The trade-off: content is always fresh, but TTFB is higher because the server must do work before responding.

Incremental Static Regeneration (ISR)

ISR is the middle ground. Pages are statically generated at build time (like SSG), but Next.js automatically regenerates them in the background after a configurable revalidation interval. The first visitor after the interval triggers a background rebuild; subsequent visitors get the updated page instantly.

In the App Router, you control ISR with export const revalidate = 60 (seconds) or by passing { next: { revalidate: 60 } } to fetch calls. In the Pages Router, you'd add revalidate to getStaticProps. ISR gives you CDN-speed delivery with near-real-time freshness — perfect for e-commerce catalogs, news sites, and content-heavy platforms.

The Decision Flowchart: SSR vs SSG vs ISR

Use this flowchart every time you create a new page or route in Next.js. Start at the top and follow the questions:

1. Does the page depend on request-specific data (auth, cookies, geo, personalization)?

  • YES → Use SSR. There's no way to pre-render personalized content.
  • NO → Continue to question 2.

2. Does the content change frequently (more than once per deploy)?

  • NO → Use SSG. Build once, serve forever from the CDN.
  • YES → Continue to question 3.

3. Can users tolerate slightly stale content (30s–5min old)?

  • YES → Use ISR with an appropriate revalidation interval.
  • NO → Use SSR. Freshness is non-negotiable.

This framework is deliberately simple. Most production apps use a mix of all three strategies across different routes — and that's exactly the right approach.

Real-World Examples From Production Next.js Apps

Breville — Recipe & Product Pages (SSG + ISR)

Breville's companion platform serves thousands of recipes, on-demand cooking classes, and product pages. The content is managed by a CMS and updated by the editorial team — not on every request.

We used SSG for core product pages and marketing content that changes only during planned launches. For the recipe catalog and class listings, we used ISR with a 60-second revalidation window. This meant the editorial team could publish a new recipe in the CMS, and it would appear on the site within a minute — without a full redeploy.

  • Product pages: SSG — content changes only at launch, perfect Lighthouse scores.
  • Recipe catalog: ISR (revalidate: 60) — editorial updates go live in under a minute.
  • SEO impact: Pre-rendered HTML meant Google indexed every recipe page on first crawl.

CAFU — Service Booking & Location-Based Pricing (SSR)

CAFU is a fuel delivery and vehicle services platform in the UAE. Pricing depends on the user's location, selected vehicle, and real-time fuel rates. The booking flow requires authentication and personalized data from the first paint.

SSR was the only viable choice for the booking funnel. Every page in the flow depends on cookies (auth session), geolocation, and dynamic API responses. We couldn't pre-render any of it. The marketing and landing pages, however, were pure SSG — no personalization needed, and every millisecond of TTFB matters for paid-ad landing page quality scores.

  • Booking funnel: SSR — personalized, auth-dependent, real-time pricing.
  • Marketing/landing pages: SSG — fast TTFB for Google Ads quality scores.
  • Key insight: mixing strategies within one Next.js app is the sweet spot.

Rabbit Care — Insurance Comparison (SSR + ISR Hybrid)

Rabbit Care is a large-scale InsurTech and FinTech comparison platform in Southeast Asia. The product listing pages show insurance plans with real-time pricing from multiple providers. The comparison results depend on user inputs — age, coverage, vehicle type — making them inherently dynamic.

We used SSR for the comparison results and quote pages, since every request is unique and pricing must be fresh. But the informational content — guides like "How car insurance works in Thailand" — was perfect for ISR. These pages get heavy organic search traffic, update occasionally when regulations change, and benefit enormously from CDN-cached HTML.

  • Comparison/quote pages: SSR — unique per user input, real-time provider pricing.
  • Educational guides: ISR (revalidate: 3600) — SEO-critical, updates are infrequent.
  • Result: organic traffic to guide pages jumped because Google consistently received fast, pre-rendered HTML.

Eyewa — E-commerce Product Catalog (ISR)

Eyewa is an omnichannel eyewear retailer across the GCC region with thousands of product pages. The catalog changes daily — new arrivals, price updates, stock changes — but the data doesn't need to be real-time accurate to the second.

ISR was the natural fit. We statically generated the entire product catalog at build time and set a revalidation interval of 120 seconds. This gave us the CDN speed of SSG with content freshness that matched the business requirement. Cart and checkout pages used SSR because they depend on session and inventory state.

  • Product listing/detail pages: ISR (revalidate: 120) — fast, fresh enough for catalog data.
  • Cart and checkout: SSR — session-dependent, real-time inventory checks.
  • SEO win: thousands of product pages indexed with sub-200ms TTFB from the CDN edge.

SSR vs SSG vs ISR — Side-by-Side Comparison

Time to First Byte (TTFB)

  • SSG: Fastest — served directly from CDN cache, no server computation.
  • ISR: Fast — same as SSG for cached pages; slight delay during background regeneration.
  • SSR: Slowest — server must render the page before responding.

Content Freshness

  • SSG: Stale until next deploy. Only suitable for content that rarely changes.
  • ISR: Near-real-time. Content updates within the revalidation window (30s–1hr typical).
  • SSR: Always fresh. Every request gets the latest data.

SEO Performance

  • SSG: Excellent — fast TTFB, fully rendered HTML, perfect for Core Web Vitals.
  • ISR: Excellent — same benefits as SSG with the bonus of updated content.
  • SSR: Good — fully rendered HTML, but higher TTFB can impact Core Web Vitals scores.

Scalability & Infrastructure Cost

  • SSG: Lowest cost — CDN-only, no server needed at runtime.
  • ISR: Low cost — CDN handles most traffic; server only regenerates stale pages.
  • SSR: Highest cost — every request hits your server; must scale compute with traffic.

How This Maps to the Next.js App Router

With the App Router (Next.js 13+), the rendering strategy is determined by how your page components and data fetching behave — not by exporting special functions like getStaticProps or getServerSideProps.

SSG in the App Router

  • Default behavior — if your page has no dynamic functions, it's statically rendered at build time.
  • Use generateStaticParams for dynamic routes to pre-render specific paths.
  • Explicitly mark with export const dynamic = "force-static" if needed.

SSR in the App Router

  • Triggered by using cookies(), headers(), or accessing searchParams.
  • Or explicitly with export const dynamic = "force-dynamic".
  • Fetch calls with { cache: "no-store" } also force dynamic rendering.

ISR in the App Router

  • Set export const revalidate = 60 at the page or layout level.
  • Or pass { next: { revalidate: 60 } } to individual fetch calls.
  • On-demand revalidation via revalidatePath() or revalidateTag() for instant cache busting.

Common Mistakes When Choosing a Rendering Strategy

  1. Using SSR when SSG would work: If your page doesn't depend on request data, don't pay the TTFB penalty. Default to SSG and only opt into SSR when you have a real reason.
  2. Setting ISR revalidation too low: A revalidation interval of 1 second is effectively SSR with extra complexity. If you need data that fresh, just use SSR.
  3. Forgetting that ISR serves stale content during regeneration: The revalidation is background — the user who triggers it gets the old page. If your business can't tolerate any staleness (financial data, live inventory counts), use SSR.
  4. Ignoring the CDN layer: SSG and ISR pages are cached at the edge. If you add cache-busting headers or misconfigure your CDN, you lose the entire performance benefit.
  5. Not mixing strategies: There's no rule that an entire app must use one strategy. The best Next.js apps use SSG for marketing, ISR for catalogs, and SSR for personalized flows — in the same codebase.

Performance and SEO Impact: Why Your Rendering Strategy Matters

Google's Core Web Vitals directly affect search rankings. Largest Contentful Paint (LCP) and Time to First Byte (TTFB) are heavily influenced by your rendering strategy. SSG and ISR pages consistently score higher because the HTML is pre-built and served from edge locations closest to the user.

From the Breville and Eyewa projects, we measured a 40–60% improvement in TTFB when moving product and recipe pages from SSR to ISR. Google Search Console showed a corresponding improvement in crawl efficiency — more pages indexed per crawl budget, and faster indexing of new content.

For SEO-critical pages, the priority order is clear: SSG > ISR > SSR. Use SSG when you can, ISR when content updates matter, and SSR only when personalization demands it.

Summary: When to Use SSR, SSG, and ISR

Choose SSG when:

  • Content changes only at deploy time (about pages, docs, blog posts, marketing).
  • Maximum performance and lowest infrastructure cost are priorities.
  • SEO is critical and content doesn't need to reflect real-time changes.

Choose SSR when:

  • The page depends on cookies, auth, headers, or request-specific data.
  • Content must be 100% fresh on every request (real-time pricing, live dashboards).
  • Personalization or A/B testing requires server-side logic before rendering.

Choose ISR when:

  • Content updates frequently but staleness of 30 seconds to a few minutes is acceptable.
  • You have a large number of pages (product catalogs, blog archives) that can't all be built at deploy.
  • You want CDN-speed delivery with near-real-time content freshness.

Final Thoughts

The right rendering strategy isn't a global setting — it's a per-page decision. The best Next.js apps I've worked on (Breville, CAFU, Rabbit Care, Eyewa) all use a mix of SSG, SSR, and ISR across different routes. The framework gives you the flexibility; the decision flowchart above gives you the structure to choose correctly every time.

Start with SSG as your default. Upgrade to ISR when content freshness matters. Resort to SSR only when the page genuinely depends on request-time data. This simple hierarchy keeps your app fast, your SEO strong, and your infrastructure costs under control.