Static vs Dynamic Rendering in Next.js Explained

Static vs dynamic rendering in Next.js 16 is decided per component, not per route. Static means work that finishes at build time and ships as prerendered HTML. Dynamic means work that waits for the request because the data is not known until then.

This article assumes Cache Components, enabled with cacheComponents: true in next.config.ts. Under that model data is dynamic by default, and you opt in to static output with the use cache directive.

Static and dynamic at a glance

The two modes answer one question: when does this component run?

A static component only needs inputs available at build time. A dynamic component needs something that only exists once a real visitor arrives.

What makes a component static

Components that use only predictable values prerender automatically. Module imports, synchronous file reads, and pure computations produce the same output every time, so Next.js runs them once at build time and bakes the result into the shell.

App.tsx

// app/about/page.tsx
import fs from 'node:fs'
 
export default function AboutPage() {
  const content = fs.readFileSync('./about.txt', 'utf-8')
  return <article>{content}</article>
}

This page is fully static. It reads no request data, so next build renders it once, stores the HTML, and serves the same output to every visitor without running the component again.

What makes a component dynamic

A component becomes dynamic when it reads a request-time API or waits on uncached data. In Next.js 16 that read streams behind a Suspense boundary instead of forcing the whole route dynamic.

App.tsx

// app/dashboard/page.tsx
import { cookies } from 'next/headers'
import { Suspense } from 'react'
 
async function ThemeBanner() {
  const theme = (await cookies()).get('theme')?.value ?? 'light'
  return <p>Your theme is {theme}</p>
}
 
export default function DashboardPage() {
  return (
    <main>
      <h1>Dashboard</h1>
      <Suspense fallback={<p>Loading theme...</p>}>
        <ThemeBanner />
      </Suspense>
    </main>
  )
}

The heading is static and ships immediately. The theme banner depends on a cookie, so the fallback renders in the shell and the real banner streams in when the cookie is read. The whole page does not become dynamic just because one part reads a cookie.

One page, both modes

A single route mixes static, cached, and streamed content. Static markup and cached data join the prerendered shell, while request-specific data streams behind fallbacks. First, cache the shared posts:

App.tsx

// app/lib/posts.ts
import { cacheLife } from 'next/cache'
 
export async function getLatestPosts() {
  'use cache'
  cacheLife('hours')
  const res = await fetch('https://api.example.com/posts')
  return res.json()
}

Then compose the page with one cached read and one streamed read. PersonalFeed is the cookie reading component from the previous section, moved into its own file so the page stays small.

App.tsx

// app/blog/page.tsx
import { Suspense } from 'react'
import { getLatestPosts } from '../lib/posts'
import { PersonalFeed } from './personal-feed'
 
export default async function BlogPage() {
  const posts = await getLatestPosts()
  return (
    <main>
      <h1>Blog: {posts.length} posts</h1>
      <Suspense fallback={<p>Loading your feed...</p>}>
        <PersonalFeed />
      </Suspense>
    </main>
  )
}

The heading and the cached post count prerender into the shell, because getLatestPosts is cached and resolves at build time. The personal feed reads a cookie, so it streams in at request time. This is Partial Prerendering, and it is the default when Cache Components is on.

The pre-Cache-Components model

Older Next.js used route segment config such as export const dynamic = 'force-dynamic' and export const revalidate to control rendering per route. That model still works when Cache Components is disabled, but it is a different system from the component-level decision described here.

If you are keeping the older model, see caching without Cache Components. The modern path needs no per-route config, because one page already mixes both modes automatically.