Full Route Cache

The Full Route Cache is a server-side cache that stores the rendered output of your routes — the generated HTML and the React Server Component (RSC) payload — at build time or after the first request. Its purpose is simple: if a route can be rendered once and reused for every visitor, Next.js should never waste server or database cycles rendering it again.

This cache is what makes statically rendered routes in the App Router so fast in production. When a request comes in for a route that has an entry in the Full Route Cache, Next.js skips rendering entirely and serves the cached HTML and RSC payload directly, whether that request comes from the first visitor or the millionth.

How entries get created

An entry is added to the Full Route Cache whenever a route is statically rendered. That happens in two situations:

At build time, for any route that Next.js determines can be fully static (no dynamic functions, no uncached dynamic data).
On-demand, the first time a route using Incremental Static Regeneration (ISR) is requested after a revalidation window has passed.

TSX

// app/blog/[slug]/page.tsx
// Statically rendered at build time (or on first request with ISR)
export const revalidate = 3600 // regenerate at most once per hour

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <article>{post.title}</article>
}

Full Route Cache vs. Data Cache

Note

It is easy to conflate the Full Route Cache with the Data Cache, but they store different things and are invalidated independently.

Cache	What it stores	Scope
Data Cache	Raw results of individual fetch() calls	Persists across requests and deployments
Full Route Cache	Rendered HTML + RSC payload for a route	Persists across requests, tied to the deployment

A route can only be added to the Full Route Cache if all of the data it depends on is itself cacheable. If a page reads from the Data Cache but that data changes, the route won't automatically re-render until it is revalidated or the whole route is rebuilt — the two caches work in layers, with the Data Cache feeding the render that the Full Route Cache then stores.

Invalidating the Full Route Cache

Revalidating data — calling revalidatePath() or revalidateTag() clears the cached render for the affected route(s).
Time-based revalidation — export const revalidate = <seconds> on a route regenerates it after the window expires.
A new deployment — every deploy wipes the Full Route Cache clean, since it is tied to the current build.

TSX

import { revalidatePath } from 'next/cache'

export async function publishPost(id: string) {
  await db.post.update({ where: { id }, data: { published: true } })
  // Clears the Full Route Cache entry for /blog and lets the
  // next request regenerate it with fresh data
  revalidatePath('/blog')
}

Routes that opt out automatically

Not every route is eligible. Next.js will skip the Full Route Cache entirely for a route that:

Reads cookies() or headers() to make a rendering decision.
Uses searchParams in a way that affects the render.
Calls fetch() with { cache: 'no-store' }, or the route sets export const dynamic = 'force-dynamic'.

Warning

Any of these makes the route dynamically rendered on every request, meaning it never gets an entry in the Full Route Cache — you pay the full render cost per request in exchange for always-fresh, per-request output.

Tip

You can inspect which routes were statically generated at build time by running next build — the output table marks each route as ○ (Static), ● (SSG), or λ (Dynamic), which is the quickest way to confirm whether a route is eligible for the Full Route Cache.