Static & Dynamic Rendering

Next.js wants to render every page at build time if it can. Pages that can are called static. Pages that depend on something only known at request time are called dynamic. The choice happens automatically — but you can override it.

What makes a page dynamic

• Using cookies() or headers() from next/headers
• Reading searchParams inside the page
• Calling fetch(url, { cache: "no-store" })
• Using dynamic = "force-dynamic" (explicit opt-in)

Touch any of those and the page renders at request time. Otherwise it's prerendered at build time and served as static HTML.

Explicitly setting the mode

Each route can export a dynamic constant to declare its mode:

// app/feed/page.js
export const dynamic = "force-dynamic";   // always render at request time
// or
export const dynamic = "force-static";    // never render at request time

• **"auto"** (default) — let Next.js decide based on what the page uses.
• **"force-dynamic"** — render on every request.
• **"force-static"** — render once at build; error if the page tries to do something dynamic.

Revalidate (ISR)

A static page can be regenerated after a delay. Export revalidate:

// app/page.js
export const revalidate = 60;   // re-render at most once every 60 seconds

Visitors get the cached HTML; in the background Next.js rebuilds when the timer expires. This is incremental static regeneration (ISR). It's the easiest way to keep a mostly-static page fresh without making it fully dynamic.

Picking a mode

• Marketing, docs, blog — static, sometimes with revalidate.
• Logged-in dashboard, search results — dynamic.
• Product listing that changes daily — static with revalidate = 3600.