When does a static route without "use cache" get re-rendered?

[dninomiya]

I assumed that a route without "use cache" would render only at build time,
but based on my observation, that doesn’t seem to be the case.

After deploying a static page without "use cache", I noticed that console.log runs again if I revisit the page after some time.
Sometimes it logs three times on three consecutive refreshes, and then stops logging for a while —
so it doesn’t look like it’s fully dynamic either.

Could someone clarify when such a route is re-rendered (or revalidated)?
Is there some internal caching or time-based revalidation happening automatically for routes that don’t use "use cache"?

export default function Page() {
  console.log("static page rendered");

  return <p>Static Page</p>;
}

[icyJoseph]

Is that all there's to the route? And Cache Components enabled right? Where/how's this deployed?

[dninomiya]

@icyJoseph

Thank you for your support!

Here’s what I did:

1. Set up a new environment with the latest version of Next.js.
2. Added console.log statements to both layout.tsx and page.tsx, then deployed to Vercel.

After waiting for a while and reloading the page, the console.log outputs appeared in the Vercel logs.

I also created a test page that uses faker, and after leaving it for a few minutes and refreshing, the displayed name sometimes changes — though not always, and I haven’t figured out the exact pattern yet.

• I haven't measured it precisely, but if you wait approximately 15 to 30 minutes before reloading, the logs will start flowing again.
• No new deployments were made during the period when multiple console.log outputs were appearing.

layout.tsx with "use cache"
https://use-cache-static-demo.vercel.app/ <- with faker for debug
https://use-cache-static-demo.vercel.app/clean <- clean page

layout.tsx without "use cache"
https://use-cache-static-demo-git-without-use-cache-deer-inc.vercel.app/

code
https://github.com/dninomiya/use-cache-static-demo

log

---

"next": "16.0.0"

2025-10-28.10.22.36.mov

[dninomiya]

@icyJoseph
I noticed that when "use cache" is set in layout.tsx, it implicitly applies "use cache" to all routes. Just to confirm — is this the intended behavior?

In other words, if I want to achieve fully static pre-generation, should I avoid setting "use cache" in layout.tsx?

[icyJoseph]

My bad, I only looked at the snippet in your OP - 🤦 - when you use use cache w/o profile, then the default is used, and that one has revalidate of 15 minutes. After 15 minutes, if a request arrives, it gets served stale content, and then in the background, the content is regenerated.

use cache is meant to allow you to make dynamic data part of the static shell, roughly speaking of course. If your pages are nothing but static content, all of it will be included into the static shell, the end case being that the entire page is just static.

The build output hints at this, w/ use cache:

Route (app)      Revalidate  Expire
┌ ○ /                   15m      1y

Without:

Route (app)
┌ ○ /                   

It might be the case that you read your content from file system and such (technically dynamic data), you maybe want to use max cacheLife 🤔

[dninomiya]

@icyJoseph
Thank you for your response!

I’ve confirmed that when use cache is not used, the page is built only once at build time.
However, if any part of the page (including layouts) uses use cache, the entire page will be regenerated according to the shortest cache duration among them.

Since it’s not realistic to avoid using use cache across all layouts and components, I solved this by attaching a custom cache only to the parts that I want to be one-time builds.

export default function Page() {
  "use cache";
  cacheLife("infinite");

  return <div>...</div>
}

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
  cacheLife: {
    infinite: {
      stale: Number.MAX_VALUE,
      revalidate: Number.MAX_VALUE,
      expire: Number.MAX_VALUE,
    },
  },
};

export default nextConfig;

However, if a lower-level component within the page has a shorter cache duration, that duration takes precedence.
Therefore, it’s generally better to apply use cache together with cacheLife("infinite") to functions that you want to behave as fully on-demand.

[icyJoseph]

I think you only needed a very high revalidate right? - the stale key is for the client router to keep on re-using data before checking with the server. revalidate is the time after which, the next request triggers revalidation (what you are observing) but still serves stale data, the revalidate clock goes back to zero after.

expire is the time since the start or last revalidation, after which the next request, has to block, it has to be higher than revalidate, because the data must first be stale.