Rendering Strategies

Next.js determines how and when to render each page. Understanding rendering strategies is essential for balancing performance (speed) with freshness (up-to-date data).

Static Rendering (SSG)

HTML is generated at build time and served from a CDN. This is the fastest rendering strategy — the server does zero work per request.

// This page is static by default (no dynamic functions)
async function BlogList() {
  const posts = await fetch('https://api.example.com/posts',
    { cache: 'force-cache' }
  );
  return <PostList posts={await posts.json()} />;
}

Static pages are pre-built during next build. They're ideal for content that doesn't change per user or per request: blog posts, documentation, marketing pages, product listings.

For dynamic routes (/blog/[slug]), use generateStaticParams to tell Next.js which pages to pre-render:

export async function generateStaticParams() {
  const posts = await getPosts();
  return posts.map(post => ({ slug: post.slug }));
}

Dynamic Rendering (SSR)

HTML is generated on the server for each request. The page always has fresh data but is slower than static because the server must render on every request.

A route becomes dynamic when it uses any dynamic function:

• cookies() — reads request cookies
• headers() — reads request headers
• searchParams — reads URL query parameters
• fetch() with cache: 'no-store'

Next.js automatically detects these and switches to dynamic rendering — you don't need to configure it.

Incremental Static Regeneration (ISR)

ISR combines static performance with periodic data freshness. Pages are statically generated but revalidate after a time interval:

// Page-level: revalidate every hour
export const revalidate = 3600;
 
// Or per-fetch:
fetch(url, { next: { revalidate: 3600 } });

How ISR works:

1. First request: serves the static page (built during next build)
2. After revalidation period: next request triggers a background regeneration
3. Stale page is served immediately while the new version is built
4. Once regeneration completes, subsequent requests get the fresh page

This is the stale-while-revalidate pattern — users never wait for regeneration.

Streaming

Streaming sends HTML progressively as parts of the page become ready, instead of waiting for everything:

import { Suspense } from 'react';
 
async function Dashboard() {
  return (
    <>
      <Header />  {/* Immediate */}
      <Suspense fallback={<ChartSkeleton />}>
        <SlowChart />  {/* Streams when ready */}
      </Suspense>
      <Suspense fallback={<TableSkeleton />}>
        <SlowTable />  {/* Streams independently */}
      </Suspense>
    </>
  );
}

Each Suspense boundary streams independently. The static shell renders immediately, dynamic parts fill in as they resolve. This dramatically improves Time to First Byte (TTFB) and perceived performance.

Choosing a Strategy

Next.js makes this decision automatically based on your code:

• No dynamic functions → Static (fastest, cached at CDN)
• revalidate export or next.revalidate → ISR (static with periodic refresh)
• Dynamic functions (cookies, headers, searchParams, no-store) → Dynamic (fresh per request)
• Suspense boundaries → Streaming (progressive delivery)

The decision tree: Can the page be pre-rendered ahead of time? → Static/ISR. Does it need per-request data (user session, real-time)? → Dynamic. Can parts load independently? → Add Streaming.

Pages Router Comparison

• getStaticProps → Static rendering (default in App Router)
• getServerSideProps → Dynamic rendering (use dynamic functions)
• getStaticProps + revalidate → ISR (use export const revalidate)
• getStaticPaths → generateStaticParams

Key Interview Distinction

Static (SSG) renders at build time — fastest, served from CDN. Dynamic (SSR) renders per request — always fresh. ISR revalidates static pages on a timer — stale-while-revalidate. Streaming sends HTML progressively via Suspense. Next.js automatically determines the strategy based on whether you use dynamic functions (cookies, headers, searchParams, no-store).