Next.js ISR vs SSR: When to Use Each Strategy

Introduction

Next.js offers multiple rendering strategies, and choosing between Incremental Static Regeneration (ISR) and Server-Side Rendering (SSR) is one of the most consequential architectural decisions you will make. Each approach has distinct performance characteristics, caching behaviors, and infrastructure requirements.

This guide breaks down when to use ISR, when SSR makes more sense, and how to combine them effectively in a single application.

How ISR Works

ISR pre-renders pages at build time and then regenerates them in the background at a configurable interval. Users always see a cached version while the fresh page is being built:

// app/products/[slug]/page.tsx
export const revalidate = 3600; // Regenerate every hour

export default async function ProductPage({
  params,
}: {
  params: { slug: string };
}) {
  const product = await fetchProduct(params.slug);
  return (
    <article>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </article>
  );
}

ISR is ideal for content that changes periodically but does not need to be real-time: product catalogs, blog posts, documentation pages, and marketing landing pages.

How SSR Works

SSR generates the page on every request. There is no cached version — each visitor gets freshly rendered HTML:

// app/dashboard/page.tsx
export const dynamic = "force-dynamic";

export default async function DashboardPage() {
  const stats = await fetchDashboardStats();
  return (
    <section>
      <h1>Dashboard</h1>
      <p>Active users: {stats.activeUsers}</p>
      <p>Revenue today: {stats.revenue}</p>
    </section>
  );
}

SSR is necessary when the page content depends on the request itself — user sessions, real-time data, personalized recommendations, or content behind authentication.

Performance Comparison

| Factor | ISR | SSR | |--------|-----|-----| | Time to First Byte | ~50 ms (cached) | 200-500 ms | | Server load | Very low | Scales with traffic | | Content freshness | Delayed by revalidate interval | Real-time | | CDN compatibility | Fully cacheable | Requires edge functions or bypass | | SEO | Excellent | Excellent |

Combining Both Strategies

Most production applications benefit from using both. Use ISR for public, content-heavy pages and SSR for authenticated or highly dynamic sections:

/                 → ISR (revalidate: 3600)
/products/[slug]  → ISR (revalidate: 1800)
/blog/[slug]      → ISR (revalidate: 86400)
/dashboard        → SSR (force-dynamic)
/cart             → SSR (force-dynamic)
/account          → SSR (force-dynamic)

This hybrid approach gives you the best of both worlds: near-instant page loads for public pages and always-fresh data for user-specific views.

For a deeper look at content delivery strategies, see our guide on content delivery for e-commerce sites. Our architecture planning service helps teams design rendering strategies that balance performance and freshness.

ISR and SSR are complementary tools, not competitors. Use ISR wherever possible for its performance and cost advantages, and reserve SSR for pages that genuinely require per-request freshness. Getting this balance right is the key to a fast, scalable Next.js application.