#Static vs Dynamic vs Streaming¶

Next.js gives you four ways to render a page. Pick the right one and you get amazing performance for free. Pick the wrong one and you serve stale data or slow requests.

The Four Strategies¶

How Next.js Picks for You¶

Next.js infers the strategy from what your page does:

• If your page only reads cached data and doesn't touch cookies() / headers() / searchParams → static.
• If it reads dynamic APIs but you've enabled "use cache" + tags → ISR-style.
• If it reads dynamic APIs and no caching is opted in → dynamic.
• If you've enabled experimental_ppr and used <Suspense> for dynamic islands → PPR.

Explicit Overrides¶

You can force a strategy from any page.tsx or layout.tsx:

1// Force static (build will fail if anything dynamic is used)
2export const dynamic = "force-static";
3
4// Force dynamic (every request)
5export const dynamic = "force-dynamic";
6
7// Allow Next.js to decide (default)
8export const dynamic = "auto";

1// Revalidate this segment every 60s
2export const revalidate = 60;

A Worked Example¶

A blog has three routes:

A real app mixes all four routinely. Next.js doesn't make you choose one for the whole app.

How to See What Next Chose¶

After next build, you'll see a table like:

If you expected /blog to be ○ and you're seeing λ, something on the page is dynamic.

Common Surprises¶

• Calling new Date().toISOString() directly in JSX → dynamic in some cases. Wrap in a Client Component or a cached function.
• Importing a library that reads env at module top → can dynamicize routes by accident.
• Calling fetch with cache: "no-store" → forces dynamic.

Use the next build output as the ground truth for what's static and what isn't.