Static vs Dynamic Rendering

A route is static when Next can produce it ahead of time (build or revalidation) without per-request server work. It is dynamic when the response depends on request-time data (cookies, headers, uncached fetches).

Docs: Static and Dynamic Rendering.

What forces dynamic

import { cookies, headers } from 'next/headers';

export default async function Page() {
  const theme = (await cookies()).get('theme')?.value;
  // route becomes dynamic
  return <main data-theme={theme}>…</main>;
}

Also: cache: 'no-store', revalidate: 0, reading searchParams in ways that require request time (version nuances apply), and some segment config exports.

Static benefits

• CDN-friendly HTML/RSC payload
• Low TTFB for marketing and docs
• Predictable cost

Dynamic benefits

• Personalization, auth-gated UI
• Always-fresh data

Segment config

export const dynamic = 'force-static'; // or force-dynamic
export const revalidate = 60;

Prefer letting Next infer from usage; use force flags deliberately.

Hybrid pages

Static shell + dynamic holes via Suspense and cached children is the sweet spot — stream personalized bits without dynamizing everything.

Interview out-loud

“Static routes can be cached at the edge; dynamic routes run per request when you use cookies, headers, or uncached data. I keep marketing static, gate personalization behind small dynamic islands, and set revalidate for ISR-like freshness.”

Related on this site

• ISR Mental Model
• Caching in Next.js Overview
• Streaming and Suspense Boundaries
• Data Fetching Patterns App Router

Further reading

• Rendering — nextjs.org
• Dynamic Rendering

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Quick self-test

Explain the concept in 60 seconds, write a minimal code sample from memory, name one footgun, and point to the primary docs. If any of those fail, reread the worked example and rebuild it in a scratch file until the model sticks under interview pressure.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides

• Auth Patterns OverviewAuth in Next.js App Router: cookies/sessions, middleware gates, server checks, and avoiding client-only security theater.
• Caching in Next.js OverviewNext.js caching layers: request memoization, data cache, full route cache, and router cache — what invalidates each.
• Client Components in Next.jsClient Components in the App Router: use client, hydration, bundling boundaries, and patterns that keep JS small.
• Data Fetching Patterns App RouterFetch data in Server Components with async/await and fetch caching: colocation, parallel requests, and client fallbacks.
• Deploying Next on VercelDeploy Next.js on Vercel: git integration, env vars, previews, build cache, and production checklist.