Static vs dynamic rendering

The two terms describe when a page's HTML is produced. Static rendering does the work ahead of time, so a CDN can hand the same file to every visitor in milliseconds. Dynamic rendering does the work on the server for each request, which lets the response change per user, per request, or per moment — at the cost of more compute and slightly slower responses.

How it works

With static rendering, the framework generates the HTML during the build (or on first request, then caches it). This is the engine behind static site generation: no per-request server work, no database call on the critical path, just a pre-built file served from the edge. In Next.js, a route in the App Router is static by default and turns dynamic the moment it reads request-time data like cookies, headers, or searchParams.

Dynamic rendering runs the page on the server for every visit. This is server-side rendering (SSR): fresh data each time, personalization, auth-gated views. The trade is real — the server has to compute and the visitor waits for that round trip, where a static page would have already arrived.

Between the two sits incremental static regeneration, which serves a cached static page but rebuilds it in the background on a schedule — most of static's speed with fresher content.

Why it matters for B2B sites

For a B2B or SaaS marketing site, almost every public page — home, pricing, blog, glossary — can be static. Crawlers (Google's and AI engines alike) get complete HTML instantly, Core Web Vitals stay strong, and there is no server in the critical path to slow down under traffic. Dynamic rendering is best kept for the handful of routes that genuinely need it, such as a logged-in app view. Picking the right mode per route is one of the first decisions when building a marketing site on Next.js: static where it fits, dynamic only where the page truly needs request-time data. For a worked comparison of the trade-offs in practice, see static vs dynamic rendering in Next.js.

FAQ

What is the difference between static and dynamic rendering?

Static rendering produces a page's HTML ahead of time (at build or deploy), then serves that same cached file to every visitor from a CDN. Dynamic rendering produces the HTML on the server for each request, so the response can change per user, per request, or per moment. Static is faster; dynamic is fresher and can be personalized.

Is Next.js static or dynamic by default?

In the Next.js App Router, a route is static by default. It opts into dynamic rendering automatically the moment it reads request-time data — for example cookies(), headers(), or searchParams — or when you set the route segment config to force dynamic behavior.

When should you use dynamic rendering?

Use dynamic rendering only when a page genuinely depends on request-time data: logged-in dashboards, personalized views, or auth-gated content. Public marketing pages — home, pricing, blog, glossary — are usually better served statically, since they are identical for every visitor and benefit from CDN delivery.

How is incremental static regeneration different from static and dynamic rendering?

Incremental static regeneration (ISR) serves a cached static page for speed, but rebuilds that page in the background on a schedule (or on demand) so the content can update without a full redeploy. It sits between the two modes: close to static's CDN speed, with content that refreshes more often than a build-time-only page.