Static vs. Dynamic Rendering

The plain-language idea

Static rendering means Next.js renders a route once, at build time, and serves that same prerendered HTML to every visitor — instant, cacheable, servable straight from a CDN. Dynamic rendering means the route is rendered fresh on the server for every single request, because something about it can only be known once a real request arrives.

Next.js decides which one a route gets automatically, per route, based on what the route's code actually does — you don't declare it up front. The trigger is a specific category of function called Request-time APIs: cookies(), headers(), searchParams, and draftMode(). Any of these accesses request-specific data that doesn't exist until a real request shows up, so a route that calls one of them can't be fully resolved at build time — it opts the whole route into dynamic rendering. Separately, a fetch() call that's explicitly told not to cache (cache: 'no-store', or revalidate: 0) has the same effect, even with zero Request-time API calls anywhere in the route.

See it in a real thing: one line flipping a route's classification

// app/dashboard/page.tsx — static: no request-time data used
export default async function DashboardPage() {
  const stats = await fetch("https://api.example.com/stats");
  const data = await stats.json();
  return <StatsView data={data} />;
}

A route with only a default fetch() call — no Request-time APIs anywhere.

BackNext

// app/dashboard/page.tsx — now dynamic: cookies() reads request data
import { cookies } from "next/headers";

export default async function DashboardPage() {
  const theme = (await cookies()).get("theme")?.value ?? "light";
  const stats = await fetch("https://api.example.com/stats");
  const data = await stats.json();
  return <StatsView data={data} theme={theme} />;
}

Nothing else changed between these two versions — same fetch, same JSX shape — but adding one cookies() call is enough to move the whole route from "prerendered once, served from cache" to "rendered on the server for every visitor." That's the entire point of the model: Next.js doesn't ask you to declare static-or-dynamic, it infers it from what your code touches, and the inference is route-wide, not line-by-line.

What people usually miss

Watch out

• The trigger is a specific, named list, not "anything that touches request data." Only cookies(), headers(), searchParams, and draftMode() count as Request-time APIs. Reading an environment variable or a build-time config file doesn't touch this at all.
• An uncached fetch is a separate trigger from Request-time APIs, not part of the same list. fetch(url, { cache: 'no-store' }) forces dynamic rendering on its own, with zero cookies/headers/searchParams calls anywhere in the route.
• The dynamic classification is route-wide, not scoped to the one function that used a Request-time API. One cookies() call in a deeply nested component can move the entire route to dynamic rendering, not just that component.
• A default (uncustomized) fetch() call is not automatically dynamic on its own — Next.js fetches it once at build time if the route has no Request-time APIs, and re-fetches per request only if the route is already dynamic for some other reason. The fetch call inherits the route's classification; it doesn't set it by itself unless explicitly told to opt out of caching.
• You can force either behavior explicitly with export const dynamic = 'force-dynamic' (always per-request) or 'force-static' (always prerendered, with cookies()/headers()/searchParams returning empty values) — useful when you want to override what the inference would have chosen.

Why this matters in interviews

"Why did adding a cookies() call suddenly make my whole page slow / stop being cached at the CDN?" is a real production question, and answering it well means explaining the inference model, not just naming cookies() as a "dynamic function" — the route-wide scope of the effect is the part that actually catches people off guard.