Static or Dynamic — Reading the Build Output

Route (app)                              Size     First Load JS
┌ ○ /                                    5.2 kB          98 kB
├ ● /learn/[topic]/[concept]             1.8 kB          95 kB
├   ├ /learn/react/react-usestate
├   └ [+199 more paths]
├ ƒ /dashboard                           3.1 kB          96 kB
└ ƒ /api/health                          0 B                0 B

// ○ Static     prerendered at build, served from the CDN. Fastest.
// ● SSG        prerendered from generateStaticParams. Also CDN.
// ƒ Dynamic    rendered per request on a server. Costs latency and money.
// λ / Edge     runs on the edge runtime.

// What to look for after a build:
//   - a page you expected to be ○ showing as ƒ
//   - First Load JS creeping up release after release
//   - a route with far more paths than you expected

// Diffing this between deploys catches regressions that no test does.
// Some teams commit the summary and review changes to it.

// Force a decision when you want it enforced rather than inferred:
export const dynamic = 'force-static'    // build fails on dynamic API use
export const dynamic = 'force-dynamic'   // never prerender

// Anything request-dependent, anywhere in the tree:
cookies()  headers()  draftMode()  connection()
searchParams as a page prop
fetch(..., { cache: 'no-store' })
export const dynamic = 'force-dynamic'
export const revalidate = 0

// And critically, these are INHERITED DOWNWARD. A cookies() call in
// app/layout.tsx makes every route in the application dynamic.

// Finding the culprit when a route unexpectedly shows ƒ:
//   1. Check the shared layouts first — that is usually it.
//   2. Search the route's tree for the calls above.
//   3. Build with the debug flag and read which access it reports:
//      "Route /problems couldn't be rendered statically because it
//       used cookies"

// The usual accidental cause: an auth helper called in a layout to
// decide whether to show a "Sign in" button. That one button makes
// the whole site render per request.
// Fix: render the auth-dependent part in its own client component,
// or isolate it behind a Suspense boundary so the shell stays static.

// A static page with a signed-in header:
//   Option A — the header reads the session on the CLIENT
'use client'
const { user } = useAuth()          // page stays static, header hydrates

//   Option B — isolate the dynamic bit behind Suspense (PPR-shaped)
<Suspense fallback={<HeaderSkeleton />}>
  <AuthHeader />        {/* reads cookies() — only this is dynamic */}
</Suspense>

//   Option C — middleware sets a header, the page reads nothing
//   (still dynamic, but cheap)

// generateStaticParams for known dynamic routes
export async function generateStaticParams() {
  return (await getAllSlugs()).map((slug) => ({ slug }))
}
export const dynamicParams = true      // render unknown ones on demand,
                                       // then cache (the usual choice)
export const dynamicParams = false     // 404 for anything unlisted

// For a large catalogue, prerender the popular ones and let the tail
// render on demand:
export async function generateStaticParams() {
  return (await getTopSlugs(500)).map((slug) => ({ slug }))
}
// 200 concept pages at build, the rest on first visit — a shorter
// build with the same user-visible speed after the first hit.