Dynamic settings for ISR cache based on route params and external APIs

[hdodov]

Goals

Have a way of setting ISR TTL based on the content, rather than statically for each route.

Non-Goals

No response

Background

The only alternative I've found is to literally copy-and-paste your route on the filesystem and provide export different cache settings, e.g.:

export const revalidate = 180
export const dynamic = 'error'

Proposal

When your data comes from a CMS, you usually have one catch-all route and you render pages based on what was visited. Something like app/[slug]/page.tsx with the following:

export const revalidate = 180
export const dynamic = 'error'

export default async function Page({ params }) {
  const { slug } = await params;
  const content = await cms.findPage({ slug });
  return <section>{content}</section>;
}

However, it makes no sense to cache all pages equally. For example, the home page receives tons of traffic and rarely changes, so it makes sense to cache it with a higher TTL, but the rest — not so much. Also, for logged-in users, you don't want to cache anything, since they must see the changes they make to the content in the CMS.

Currently, to do the above, you need to essentially develop your own router that runs in middleware.ts and uses NextResponse.rewrite to point to different copy-pasted routes that only differ in cache settings, e.g.:

• https://example.com/ → /normal-cache/home, handled by app/normal-cache/[slug]/page.tsx
• https://example.com/foo → /weaker-cache/foo, handled by app/weaker-cache/[slug]/page.tsx
• https://example.com/foo?preview=true → /no-cache/foo, handled by app/no-cache/[slug]/page.tsx

…and as you may guess, this is terrible in terms of DX and maintainability.

An ideal solution would be a single app/[slug]/page.tsx that looks like this:

import { revalidate } from "next/cache";

export default async function Page({ params }) {
  const { slug } = await params;
  const content = await cms.findPage({ slug });

  if (content.frequentlyChanging) {
    revalidate(20);
  } else if (isPreview) {
    revalidate(0);
  } else {
    revalidate(180);
  }

  return <section>{content}</section>;
}

The filesystem router is designed to make routing easy and hassle-free, but in this situation, it does the exact opposite and is nothing but an obstacle that you have to overcome in an effort to build your own router..

[icyJoseph]

I have a feeling that use cache's cacheLife is the right tool for this. Let me do some testing, but at least right now, I'd expect to be able to make a request, collect some data from it and use that to set the cache life profile, as well as to render the component, and then cache the whole thing.

So you'd have:

const profile = content.frequentlyChanging ? 'minutes' : 'weeks'
cacheLife(profile)

I kind of got it working on a quick demo:

import { unstable_cacheLife as cacheLife } from "next/cache";
import { notFound } from "next/navigation";

// you'd get this from the CMS as metadata
const revalidateTimes = {
  landingPage: 10, // 10 seconds
  blogPost: 5, // 5 seconds
};

export default async function BlogPostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  "use cache";
  const { slug } = await params;

  const origin = "http://localhost:3001";
  const url = `${origin}/blog/${encodeURIComponent(slug)}`;

  const res = await fetch(url);

  if (!res.ok) notFound();

  const post = await res.json();

  const revalidate =
    slug === "landing-page"
      ? revalidateTimes.landingPage
      : revalidateTimes.blogPost;

  cacheLife({ revalidate });

  return ( /* JSX */ );
}

Screen.Recording.2025-08-22.at.23.57.21.mov

Something like that... I need to study and refine the mental model around use cache, but this seems to do the trick.