Next.js 16.4: Keep Marketing Pages Static

Set a rendering requirement before changing configuration

Next.js 16.4 introduces ensureStatic, a route setting for keeping selected server-rendered output static. It can cover the application shell, per-link prefetches, or the complete route. The release announcement presents it as protection against unwanted request-time rendering on sites such as marketing pages and blogs.

For a business website, start with a decision rather than a configuration change: which pages must return shared content, and which genuinely need visitor-specific server output? Treat the answer as a rendering budget. Here, “budget” means an agreed boundary for server work, not a measured hosting allowance.

Our recommendation is to record the required rendering behavior alongside each page's content requirements. Ask the content owner whether personalization is essential, and ask the developer where that personalization runs. Do not make a cost-saving promise before measuring the deployed result.

The distinction matters because Cache Components can combine prerendered UI, cached content and request-specific server content within one route. Static output does not depend on request-specific data, according to the official guide.

Choose the correct level of protection

The ensureStatic reference defines three increasingly strict levels:

• 'shell': requires the App Shell loaded by a default Link to be static. Request-specific content behind Suspense can render during a later prefetch or navigation.
• 'prefetch': requires both the shell and per-link prefetches to be static. Request-specific content behind Suspense waits for navigation.
• 'navigation': requires the complete server-rendered route to be produced during prerendering, covering initial loads and client navigations.

For a page whose complete server output must remain static, choose 'navigation'. Do not describe 'shell' or 'prefetch' as equivalent protections: neither adds build validation. The reference explicitly distinguishes their stage behavior from the complete static-output validation performed for 'navigation'.

Check prerequisites before applying any setting. ensureStatic requires Cache Components; exporting it without that feature fails the build. Exporting it from a Client Component also produces an error. The shell and prefetch guarantees depend on Partial Prefetching, whereas 'navigation' works with Cache Components alone.

The worked guide enables both features in next.config.ts:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
}

export default nextConfig

Merge these settings into the existing configuration rather than replacing unrelated options. Treat adoption as a reviewed application change, not just a switch to toggle before deployment.

Put the requirement at the right boundary

The reference provides a compact layout example for enforcing static navigation across a blog section:

// app/blog/layout.tsx
export const ensureStatic = 'navigation'

export default function Layout({ children }: { children: React.ReactNode }) {
  return <>{children}</>
}

This is a documentation example, not a claim that every blog should use the same architecture. Choose a layout boundary only after reviewing the routes it contains.

Scope is broader than the file containing the export. A layout setting applies to every route that renders that layout. Within each route, the requirement also covers ancestor layouts. A root-layout setting therefore applies throughout the app. Descendants may strengthen a parent's level, but attempting to weaken it fails the build, as explained in the scope rules.

Our recommendation: begin with a narrowly selected public section. Review shared navigation, metadata and other ancestor behavior before moving the requirement upward. If you need help defining those boundaries, include the route inventory in your Next.js development brief.

Fix the cause of a validation failure

With 'navigation', Next.js checks the complete static-output requirement in both development and production builds. Wrapping incompatible server work in Suspense does not exempt it. Neither does setting instant = false, according to the validation rules.

Review these documented failure categories:

• Uncached fetches or database calls, and calls to connection().
• Runtime data such as cookies(), headers() and server-side searchParams.
• Cache lifetimes that violate the static-output constraints.
• Request-dependent server promises passed to Client Components, even if those components never read them.

The same constraints apply to generateMetadata and generateViewport. Include both in the review rather than checking only the visible page component.

The reference's cache limits are specific: an expire below five minutes, a stale below 30 seconds, or a revalidate of zero fails validation. A stale value between 30 seconds and five minutes is allowed. Do not assume that adding a cache directive automatically makes every lifetime compatible.

For genuinely shared data, the guide demonstrates adding 'use cache' to the data-access function. For request-specific data, it describes removing the access or moving the read to the client. Decide which behavior the page needs before choosing a fix; do not weaken the requirement merely to obtain a passing build.

Review dynamic URLs separately

A dynamic route using 'navigation' must export generateStaticParams() and return at least one complete parameter set. Every dynamic parameter must be included, even when unused or read only in a Client Component. Missing or incomplete parameters fail the build, according to the dynamic-parameter reference.

Avoid another misleading shortcut: static output does not mean every possible URL was generated at build time. For a parameter value not prerendered during the build, Next.js waits for the static result to be generated before serving it, according to the same reference.

For acceptance testing, list the known URLs and separately identify allowed URLs that were not included in build-time generation. Review their first-request behavior instead of assuming they behave identically to already-prerendered pages.

Make the rollout testable and measure the result

Use a small acceptance checklist before deployment:

1. Record the required level for each selected route and its layout scope.
2. Run next build and inspect static-output failures.
3. Investigate failures in next dev, or use next build --debug-prerender for detailed build traces.
4. Check initial loads, internal navigation and any intended personalized content.
5. Compare production request volume and resource usage after rollout.

The official guide supports the build and debugging workflow. The remaining checklist items are our recommended review process, not reported test results for your application.

Keep rendering validation separate from navigation-experience testing. The reference explains that instant validates whether navigation can update the UI immediately; ensureStatic controls which server output must avoid request-time work.

In its v0 implementation report, Vercel describes tracking cache spend, request volume, active CPU and data transfer after navigation changes. Use those as measurement categories, not transferable savings claims. This is a vendor case study, not independent evidence of results for your site.

The practical goal is a documented rendering requirement backed by the appropriate checks. Pair that work with a website speed review, and report observed results separately from framework guarantees. Hosting savings, ranking improvements and conversion gains for your application remain unverified until measured.