static Router Cache is used once, the value of staleTimes.dynamic is applied the next time.

[AkifumiSato]

Link to the code that reproduces this issue

https://github.com/AkifumiSato/nextjs-stale-time-issue-demo

To Reproduce

1. pnpm clean-start.
2. Access http://localhost:3000.
3. Click link to /static.
4. Your devtools network tab show that the request is not made.
5. Browser back to / soon(under 3 seconds).
6. Click link to /static again.
7. Your devtools network tab show that the request is made.

Current vs. Expected behavior

My staleTimes configuration is:

const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 3,
      static: 10,
    },
  },
};

I expect that staleTimes.static is applied all times, but only the first time. After that, staleTimes.dynamic is applied.

Provide environment information

$ pnpm next info

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:44 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.12.2
  npm: 9.8.0
  Yarn: 1.22.22
  pnpm: 8.15.7
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Navigation

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

No response

[ztanner]

Hi @AkifumiSato -- the names "static" and "dynamic" do not relate to the page rendering type, but rather different categories of "liveness" that can be configured. The actual heuristic of whether to use dynamic or static is based on the prefetch prop. From the docs:

The dynamic property is used when the prefetch prop on Link is left unspecified.
The static property is used when the prefetch prop on Link is set to true, or when calling router.prefetch.

The different properties of this config refer to variable levels of "liveness" and are unrelated to whether the segment itself is opting into static or dynamic rendering. In other words, the current static default of 5 minutes suggests that data feels static by virtue of it being revalidated infrequently.

So in this case, static will influence:

• How long a loading.js segment is held onto before being refetched from the server
• How long a segment with prefetch={true} will be held onto before being refetched from the server.

If you modify the Link components to have prefetch={true}, you'll see that your static staleTime property is used.

Let me know if I misunderstood your question!

[AkifumiSato]

@ztanner Thank you for response.

The dynamic property is used when the prefetch prop on Link is left unspecified.

I tried with prefetch={undefined} for a static rendered page and staleTimes.static was applied until the cache was first used. After the second time, staleTimes.dynamic is applied. This seems to be caused by isFirstRead.

next.js/packages/next/src/client/components/router-reducer/reducers/navigate-reducer.ts

Lines 213 to 215 in 750ae91

	prefetchValues.status === PrefetchCacheEntryStatus.stale &&
	!mutable.onlyHashChange &&
	!isFirstRead

I think the documentation needs to be changed to describe up to the first use of the cache or to a simpler specification. What do you think?

[ztanner]

Ahh, I see what you mean @AkifumiSato -- let me take a closer look at why we needed that condition and I'll get back to you!

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.