Data Fetching and Caching

No scheduler is involved. The number is a staleness window in seconds: after 3600 seconds the cached page is merely marked stale, and only the next incoming request for that route causes Next.js to regenerate it.

Passing cache: 'force-cache' stores that fetch's response in Next's server-side Data Cache so later requests reuse it instead of calling the origin. In Next 15 and 16 that is not the default: a bare fetch is uncached.

The 60 seconds belongs to that one Data Cache entry — the one keyed from that URL and those options — not to the component, the page, or any other fetch. Supplying it also opts the fetch into caching.

Four layers: Request Memoization (one render pass, server memory), the Data Cache (persistent server store of fetch results), the Full Route Cache (prerendered route output on the server), and the Router Cache (visited segments in browser memory for the session).

revalidatePath invalidates cached output by route path, so you must know every URL affected by a change. revalidateTag invalidates every cached entry labelled with that tag, wherever it lives, so one call can refresh many routes at once.

The client-side Router Cache. It keeps the payload of already-visited route segments in browser memory, so a soft navigation renders from memory while a full reload discards it and goes to the server. Confirm by checking that other browsers and direct server responses are fresh.

Next.js rejects it: request-time APIs such as cookies() and headers() cannot be called inside a 'use cache' function, because a cached entry is shared across requests and would hand one user's data to another. Read the session outside the cached function and pass the values you need in as arguments.

No. That call runs in the browser, where fetch is the platform's own function and the Next-specific next option is simply ignored. Next's Data Cache is a server-side store that browser requests never write to.

The two server-side layers — cached fetch responses and stored route output — are shared, so both users can be served the same copy. The browser's Router Cache is private to one session, and per-render memoization is scoped to a single render so nobody else ever sees it.

The 'use cache' directive marks a file, async function, or component as cacheable. Next.js runs it once, stores the returned value on the server under a key derived from its inputs, and reuses that value on later requests until it is revalidated.

The tag is a label written onto the Data Cache entry that fetch creates, so the entry can later be invalidated by name. It does nothing unless the fetch is actually cached — an uncached fetch stores no entry to label.

One. React memoizes fetch calls with the same URL and options within a single server render, so the three calls collapse into one. That memoization is scoped to that one render: it is not shared across requests, users, or non-fetch data access.

Opt out at the narrowest scope that fixes the bug: no-store on the one fetch, or connection() in the one component that must run per request. Forcing the whole segment dynamic re-runs all six reads on every request and ends prerendering for the route.

The first request found an expired cache entry, was served the stale copy immediately, and triggered a background regeneration. That regeneration finished and replaced the entry, so the reload was served the newly rendered page.

cacheLife() sets the lifetime profile of a 'use cache' entry. Its three values separate concerns: stale is how long a client may reuse the value without re-checking, revalidate is how often the server refreshes it in the background, and expire is the maximum age past which the value can no longer be served.

Next.js keys a 'use cache' entry on everything that flows into the call: the serialized arguments plus the values the function closes over. Both must be serializable to be part of the key, and the returned value must be serializable because it is what gets stored and replayed.

React's cache() deduplicates calls within a single server render: several components asking for the same data run the work once, and the memo is discarded when the render ends. Next's 'use cache' stores the result in a persistent server cache that survives across requests and users until it is revalidated.

Next's Data Cache is one server-side store shared by every request, and its entries are keyed from the fetch URL plus the options passed. If nothing in that key varies per user, the first visitor's profile is served to everyone else.

The persistent server data layer is designed to survive a deployment, so cached responses come back after the new build ships. Stored route output is a build product and is replaced. Per-render memoization is irrelevant, and the browser's Router Cache lives in each open tab until it reloads.

Read the build output to see exactly which routes went dynamic, then look for an opt-out placed too high: force-dynamic or revalidate = 0 in a shared or root layout, an awaited connection() in a shared component, or a no-store buried in a helper every page imports. Push it down to the one place that needs it.

Have the CMS call a Route Handler in the deployed app on publish. The handler verifies a shared secret, maps the payload to the tags or paths the change touches, calls revalidateTag or revalidatePath, and returns quickly. Keep a time window as a backstop.

Do not restore the old default globally. Classify each fetch by whether its response is shared across all users and how stale it may be, opt in only the shared ones with force-cache or an interval, and treat the upgrade as the moment to make caching intent explicit.

Treat it as a data-classification exercise, not a search-and-replace. Measure which routes actually regressed, cache the expensive user-independent work first with explicit lifetimes and tags, leave request-specific work uncached, and roll out route by route with staleness and hit-rate signals in place.

Awaiting connection() tells Next that rendering must wait for a real user request, so everything after it is excluded from prerendering. It is the opt-out for code with no data fetch at all, such as a component reading the clock or a random value.

The rule buys less correctness than it looks like and costs more than the team expects: rendering per request does not guarantee a user sees fresh data, while every route now pays a server render and origin capacity scales with traffic instead of with content change.

Decide per content type from an explicit staleness budget: windows where being minutes old is acceptable and no change event exists, event-driven invalidation where a change must be visible immediately or a reliable publish event already exists. Size tags to real change events.