Next.js Caching: ISR, Revalidation and the Data Cache

Your Next.js app is not slow because of React. It is slow because every request is doing work a cache should have absorbed. Next.js ships four caches stacked on top of each other, and the teams that understand the stack serve pages in tens of milliseconds while their database barely notices traffic.

Four caches, one mental model

Most confusion about Next.js caching comes from treating it as one cache. It is four, each with its own scope, lifetime, and invalidation story:

• Request Memoization. Deduplicates identical fetch calls within a single render pass. Ten components can call the same endpoint and the network sees one request. It lives for one request and dies. You never manage it.
• The Data Cache. Server side, persistent across requests and across deployments. Stores the responses of fetch calls (and anything you wrap in a cache function). This is where revalidate and tags operate.
• The Full Route Cache. Stores the rendered HTML and the React Server Component payload of static routes at build time or after ISR regeneration. Cleared on every deploy.
• The Router Cache. Client side, in the browser. Stores RSC payloads of visited routes so back navigation feels instant. You tune it with staleTimes, not with revalidate.

The layering matters because invalidation flows downhill. Revalidating a tag marks Data Cache entries stale, which invalidates the Full Route Cache entries built from them. Nothing you do on the server reaches into a visitor's Router Cache until their next navigation or a router.refresh().

One asymmetry trips people up constantly: the Full Route Cache is wiped on deploy, the Data Cache is not. Ship a Friday deploy and every static route regenerates, but the underlying data reads can still be served from cache. That is usually what you want. When it is not (a schema change, a poisoned entry), you need explicit purging, not a redeploy.

ISR: static pages that heal themselves

Incremental Static Regeneration is stale-while-revalidate applied to whole pages. The mechanics are precise and worth knowing exactly:

1. A page is built (at deploy time or on first request) and cached.
2. A request arrives after the revalidate window expires. The visitor still gets the cached page, instantly. No one waits.
3. That request triggers a background regeneration.
4. The next request gets the fresh page.

Two consequences follow. First, revalidate: 60 does not mean "fresh within 60 seconds". It means "at most one regeneration per 60 seconds, triggered by traffic". A page nobody visits stays stale forever, and the first visitor after a quiet period sees old content. Second, if regeneration throws, Next.js keeps serving the last good page. That is a feature (your CMS being down does not take your site down) and a trap (a silent data bug can pin stale content in place while your error logs quietly fill up).

The setup is two exports:

// app/blog/[slug]/page.tsx
export const revalidate = 3600;

export async function generateStaticParams() {
  const posts = await getPosts();
  return posts.map((p) => ({ slug: p.slug }));
}

Paths returned by generateStaticParams are prebuilt. Unknown paths are rendered on demand, then cached like the rest. Set export const dynamicParams = false if unknown slugs should 404 instead, which is the right call for finite catalogs and the wrong call for user-generated content.

One rule that surprises people: the shortest revalidate wins for a route. If the page says 3600 but one fetch inside it says 60, the whole route regenerates on the 60 second schedule. Audit your fetches before blaming the framework.

Time-based vs on-demand revalidation

Timers are a blunt instrument. They force a tradeoff between freshness and origin load, and they regenerate content that never changed. If you own the write path (your own admin panel, a CMS with webhooks, an order pipeline), event-driven revalidation is strictly better: content updates within seconds of the write, and nothing regenerates without cause.

The pattern is a webhook-driven route handler:

// app/api/revalidate/route.ts
import { revalidateTag } from "next/cache";
import { NextRequest, NextResponse } from "next/server";

export async function POST(req: NextRequest) {
  const secret = req.headers.get("x-webhook-secret");
  if (secret !== process.env.REVALIDATE_SECRET) {
    return NextResponse.json({ ok: false }, { status: 401 });
  }
  const { tag } = await req.json();
  revalidateTag(tag);
  return NextResponse.json({ revalidated: tag, now: Date.now() });
}

revalidateTag does not delete anything. It marks every Data Cache entry carrying that tag as stale, and the next request re-fetches and rebuilds affected routes. revalidatePath does the same for a specific route when you cannot tag the data cleanly. Protect this endpoint like the admin API it is; an unauthenticated revalidation route is a self-inflicted denial of service invitation. The same thinking behind API security best practices applies here.

In our experience, the best setups combine both: tags as the primary mechanism, plus a long timer (say revalidate: 86400) as a backstop for missed webhooks. Webhooks get dropped. Queues hiccup. The daily timer guarantees an upper bound on staleness no matter what.

The Data Cache in practice

Since Next.js 15, fetch is not cached by default. Caching is opt-in, per call:

const res = await fetch("https://api.example.com/products", {
  next: { revalidate: 300, tags: ["products"] },
});

That one line buys you three things: the response is stored server side, it is reused across all requests for 300 seconds, and revalidateTag("products") can purge it on demand from anywhere in your app.

The obvious gap: your database client, your ORM, your gRPC calls. None of them go through fetch, so none of them touch the Data Cache automatically. This is where teams accidentally build "static" pages that hammer Postgres on every regeneration of every route. The fix in Next.js 16 is the Cache Components model.

Cache Components: "use cache", cacheLife and cacheTag

Next.js 16 makes caching explicit with a directive instead of inference from fetch options. Enable it in config:

// next.config.ts
const nextConfig = {
  cacheComponents: true,
};
export default nextConfig;

Then mark any async function, component, or route segment as cached:

import { cacheLife, cacheTag } from "next/cache";

async function ProductGrid() {
  "use cache";
  cacheLife("minutes");
  cacheTag("products");

  const products = await db.product.findMany({
    where: { published: true },
  });
  return <Grid items={products} />;
}

This is a meaningful upgrade for three reasons:

• It caches computation, not just HTTP. Database queries, expensive transforms, and rendered component output all become cacheable with one directive.
• It is honest. Anything without "use cache" is dynamic, full stop. The old model's silent heuristics (is this fetch cached? did a header read opt me out?) are replaced by something you can grep for.
• Profiles beat magic numbers. cacheLife("minutes"), "hours", "days" and custom profiles defined in config give your team a shared vocabulary instead of arbitrary integers scattered across files.

The granularity is the real win. A page can be a cached shell with a dynamic island: the product grid carries "use cache" while the cart badge next to it reads cookies and renders per request inside a Suspense boundary. You stop choosing between "whole page static" and "whole page dynamic".

Failure modes we keep finding in audits

These are the recurring incidents, roughly ordered by how expensive they are to discover in production:

• Personalized data in a shared cache. A fetch with caching enabled that includes a user's auth token in code, with a cache key that does not include the user. User A's dashboard gets served to user B. This is the one caching bug that becomes a security incident, and it is why anything touching cookies() or session state must stay out of shared caches. Treat cache keys with the same paranoia you apply to authorization checks.
• Accidental dynamic routes. One call to cookies(), headers(), or a read of searchParams in a layout opts the entire route out of the Full Route Cache. A single analytics helper in a shared layout can quietly make your whole site dynamic. Symptom: build output shows ƒ (dynamic) where you expected ● (static).
• Self-hosting with multiple replicas. The default cache handler writes to the local filesystem. Run three containers behind a load balancer and you have three disagreeing caches, and revalidateTag only purges the replica that received the webhook. The fix is a shared cache handler (Redis is the usual choice) via the cacheHandler config option, with cacheMaxMemorySize: 0 to disable the in-memory layer. If you self-host Next.js and have not done this, your revalidation is broken and you probably have not noticed yet.
• Tag fan-out. Tagging everything "content" means every CMS edit purges the entire site, which turns your origin into a thundering herd target after each save. Tag by entity (product-123, collection-shoes) and purge narrowly.
• Timers doing event work. revalidate: 5 on a high-traffic route is dynamic rendering with extra steps and worse debuggability. If you need five second freshness, you need tags or genuinely dynamic rendering, not a fast timer.
• Deploy-time stampedes. Every deploy clears the Full Route Cache. On large sites, the minutes after a deploy send a burst of regenerations at your origin. Your database should be sized for the post-deploy burst, not the steady state, a topic we cover in database scaling patterns.

A decision framework per route

Do not pick one caching strategy for the app. Pick one per route class:

1. Classify every route. Marketing and docs pages: fully static. Catalog and content pages: static per entity. Dashboards: cached shell, dynamic islands. Checkout, account, admin: fully dynamic.
2. Default to static plus ISR for anything that is not user specific. A long timer costs nothing and removes an entire class of load.
3. Prefer tags over timers wherever you own the write path. Wire webhooks from your CMS or admin mutations to revalidateTag.
4. Keep a timer as a backstop even with tags. revalidate: 86400 bounds staleness when a webhook is lost.
5. Tag by entity, not by site section. Narrow purges, calm origins.
6. Push personalization to the leaves. Suspense boundaries and client components keep the shell cacheable and your Largest Contentful Paint element static.
7. Verify, do not assume. Check build output symbols, response headers, and origin query volume under load before calling it done.

Verifying what the cache actually does

Trust nothing until you have seen the headers. Self-hosted Next.js exposes x-nextjs-cache on responses: HIT (served from cache), STALE (served stale, regenerating in background), MISS (rendered fresh). Watching that header while you exercise a route tells you more than any amount of documentation reading.

For data-level visibility, turn on fetch logging in development:

// next.config.js
module.exports = {
  logging: {
    fetches: { fullUrl: true },
  },
};

Every fetch prints with its cache status, so a route that claims to be static but hits your API on each request exposes itself immediately. In production, the number that matters is cache hit ratio and origin query volume per route, which belongs on the same dashboards as the rest of your telemetry. If you do not have that layer yet, start with observability: logs, metrics and traces.

The payoff for getting all of this right is not abstract. A cached shell is the cheapest Time to First Byte and LCP win available in the Next.js ecosystem, and it compounds with everything in our Core Web Vitals field guide. Fast pages, small bills, boring on-call rotations. That is the goal.

How Innovation T can help

Innovation T builds and audits production Next.js applications: caching architecture, ISR and tag-based revalidation design, self-hosted cache handlers, and the observability to prove it all works under load. If your site is slower or more expensive than it should be, the cache stack is usually where we find the answer. See our web development and cloud services.

If you want a second pair of eyes on your rendering strategy, or a team to build it right the first time, talk to us. We will tell you which routes should be static by Friday.