Next 16 vs. 15 and caching the document in local dev environment

[williamj20]

Summary

I've noticed that on next version 16, there are scenarios where the document itself gets returned from cache, whereas this doesn't seem to happen on next version 15. Trying to understand if this is normal/intended as I'm not too familiar with how this stuff works, would love to learn what is happening.This only seems to happen in local dev i.e. when I run next dev.

To trigger a disk cache for the document on version 16 here's what I've been doing

1. Clone and run the "final-example" dashboard app locally here https://github.com/vercel/next-learn
2. Set Next.js version in package.json to 16.2.3 instead of latest.
3. Install packages + run dev server
4. Manually add a query parameter and go to the url i.e. http://localhost:3000?q=t
5. Manually add a different query parameter and go to the url i.e. http://localhost:3000/?q=b
6. Navigate back and forth between the two urls using the browser back button

Result: the document is cached in disk and the dev tool is constantly spinning as a result.

Version 16

Next dev tool constantly spinning as a result:

Version 15 (could not reproduce)

Additional information

No response

Example

No response

[icyJoseph]

@williamj20 did you update the Next.js version included in that dashboard app? I can't repro though with your described steps exactly, but I do know we fixed a bug that somewhat fits your description:

• Fix dev mode hydration failure when page is served from HTTP cache #92892

What people would observe is that, navigating to a starting page would work, but then a hard navigation to another page, would suddenly not execute JavaScript.

Try with next@canary - we haven't released #92892 to stable just yet.

[icyJoseph]

Good, but do try with canary momentarily, just to discard the bug we fixed 🙏

[williamj20]

I did miss a couple of key steps in my description I'm realizing.... hopefully it's more clear now. I will try with canary too

[icyJoseph]

Yeah, it looks more and more like that bug I am talking about.

[williamj20]

Ah yeah, I can no longer produce this issue on next@canary

[williamj20]

I do see the behaviour from this comment as well though

[mohamed-hossam1]

What you're seeing sounds related to the newer Cache Components / router cache behavior introduced in Next 16 rather than the page itself being "accidentally cached".

One thing I'd check is whether the behavior still reproduces with cacheComponents: false. If it disappears, that narrows the investigation considerably.

Also, if the route depends on search params, make sure those boundaries are isolated correctly. I've seen a few cases where query-string navigation behaves differently once PPR and cache-aware rendering enter the picture.

The interesting part here is that you're seeing a difference between 15 and 16 in next dev, not production. That makes me wonder whether this is an intentional dev-mode optimization/debugging artifact rather than a true caching regression.

I've been collecting notes on Next.js 16 cache architecture, Cache Components, PPR behavior, search param boundaries, and debugging weird cache-related issues here:

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

Repo:
https://github.com/mohamed-hossam1/nextjs-skills

Would be interested to hear if disabling Cache Components changes the behavior. And if the repo helps, a ⭐ is always appreciated.