How to properly implement use cache with Next.js 16 App Router — replacing old implicit caching?

[JohnHarryson94]

Hi everyone 👋
I recently upgraded from Next.js 15 to Next.js 16 and I'm trying to migrate from the old implicit caching behavior to the new explicit use cache directive.
My app uses the App Router with several dynamic routes that fetch data from an external API. Previously, Next.js handled caching implicitly via fetch() options, but this often led to confusing and unpredictable cache behavior.
Now with use cache, I have a few questions:

What's the recommended pattern for using use cache alongside Server Components that fetch from external APIs? Should I place it at the layout level, page level, or individual component level?
How does use cache interact with Partial Prerendering (PPR)? Can I combine both effectively for routes that have a mix of static and dynamic content?
For pages that need revalidation every few minutes, is use cache with a revalidation time the right approach, or should I still use ISR?
Has anyone run into issues with Turbopack builds and use cache in production?

Any examples or migration tips would be really appreciated!
Environment: Next.js 16.1, React 19, Node.js 22, Turbopack, deployed on self-hosted (not Vercel)

[nightowl0804]

1. Where to place use cache:

Place it as close to the data fetching as possible — ideally at the individual component or function level, not the layout. This gives you granular control. Example:

async function ProductList() {
  'use cache'
  cacheLife('hours')
  const data = await fetch('https://api.example.com/products')
  return <List items={data.json()} />
}

You can add it at the page or layout level, but that caches everything — which is rarely what you want with external APIs.

2. use cache + PPR:

They work great together. PPR splits your page into a static shell and dynamic parts. Use use cache on the cacheable parts, and wrap truly dynamic parts (user-specific data) in <Suspense>. The cached components become part of the static shell automatically.

export default async function Page() {
  return (
    <div>
      <CachedProductList />  {/* use cache inside */}
      <Suspense fallback={<p>Loading...</p>}>
        <DynamicUserGreeting /> {/* runs at request time */}
      </Suspense>
    </div>
  )
}

3. Revalidation every few minutes:

Use use cache with cacheLife — this replaces ISR for App Router:

import { cacheLife } from 'next/cache'

async function getData() {
  'use cache'
  cacheLife({ stale: 60, revalidate: 300, expire: 3600 })
  return fetch('https://api.example.com/data').then(r => r.json())
}

ISR still works but use cache + cacheLife is the recommended approach going forward.

4. Turbopack + use cache in production:

Turbopack builds are stable in Next.js 16. No known issues specifically with use cache. Just make sure you enable it in config:

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

For self-hosted deployments, note that use cache uses in-memory caching by default. If you're running multiple instances, consider use cache: remote with a custom cache handler to share cache across replicas — otherwise each instance maintains its own cache.

[mohamed-hossam1]

A few migration lessons from moving larger apps to Next.js 16:

• I'd avoid putting "use cache" on pages. Pages work best as orchestration layers.
• Put "use cache" on data-fetching functions or cached child Server Components.
• Create a central cache tag registry early. It becomes much easier to reason about invalidation once the app grows.
• If you're coming from unstable_cache, let Next.js handle cache keys. The biggest mindset shift is that arguments and closures are auto-keyed now.

For PPR, yes, it works well with Cache Components, but be careful around request-time APIs (cookies(), headers(), auth, params/searchParams usage). Most of the weird bugs I've debugged after migrating ended up being cache-boundary issues rather than caching itself.

For data that updates every few minutes, I'd generally use:

"use cache";
cacheLife("minutes");
cacheTag(...)

rather than thinking in ISR terms. The cache model is much more explicit now.

I ended up documenting the architecture, migration path from unstable_cache, cache tags, revalidation patterns, personalized content, search params, and debugging steps here:

https://www.skills.sh/mohamed-hossam1/nextjs-cache-architecture/nextjs-cache-architecture

Code examples:
https://github.com/mohamed-hossam1/nextjs-skills

Might save you some migration pain. If it does, a ⭐ on the repo would be appreciated.

[ssyberg]

But doesn't this become a nightmare for invalidations? How do you couple a CMS save signal with these "arbitrary to the backend" component boundaries?

[mohamed-hossam1]

That's actually why I recommend a central cache tag registry. I don't couple invalidation to component boundaries at all. Components are just consumers of domain-level tags (posts, post:42, categories, etc.). When the CMS emits a webhook, it only needs to invalidate the relevant domain tags (revalidateTag/updateTag). The component structure remains an implementation detail, so the backend never needs to know about Hero, Sidebar, or any other React boundary.

I go through the reasoning and the architecture in more detail here if you're interested: https://github.com/mohamed-hossam1/nextjs-skills/tree/main/skills/nextjs-cache-architecture

[ssyberg]

central cache tag registry

Yes, I had already come to a similar conclusion but second guessed myself because it didn't appear to be natively exposed (I suppose this is related to caching being process specific). I'm mostly following but the thing I get hung up on here is how you reliably set those tags. Let's say a fetch returns post:42 which has a nested fanout of database objects, e.g. related posts are surfaced with their titles, urls, and heros, so a single fetch for post:42 actual denormalizes data from post:11, post:33, image:77, image:66, and on and on. What's the solve there? Does that single fetch have to travel that entire graph and return all those tags along with the actual content payload? We started down such a path and found it to be too hard to reason about...