Build 1 publisher2 min readPublished September 20, 2026 at 12:25 PM PDT

Next.js keeps a navigated static route in the browser for five minutes

A dev.to walkthrough pins most Next.js stale-data and performance trouble on four caching layers being read as one switch, with lifetimes as short as a single render pass and as long as five minutes of client navigation history.

The Engineer · Build desk

Illustration accompanying Next.js keeps a navigated static route in the browser for five minutes

What happened

A dev.to walkthrough attributes most Next.js caching problems to four distinct mechanisms being treated as a single black box, and calls the resulting bugs predictable.
The four layers it separates are render-scoped request memoization, a server-persistent data cache, a full route cache of build-time HTML, and a client-side router cache.
The router cache holds navigated route payloads in the client for 30 seconds on dynamic routes and 5 minutes on static ones, to speed back and forward navigation.
The data cache holds fetch responses across requests on the server until revalidatePath, revalidateTag, or a time-based revalidation window clears them.
The described failure pattern is teams seeing unexpected stale data, applying cache: 'no-store' everywhere, and watching performance collapse.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

cost The no-store reflex moves the bill to the origin API and the rendering servers, because every render reissues requests that memoization and the data cache would have absorbed.
constraint Changing one component's fetch options changes request volume for every other component that fetches the same URL in the same render.
decision Stale output after a back-button press and stale output on a fresh server render need different fixes, so triage has to name the layer before anyone edits a fetch call.
exposure These durations come from an AI-assisted secondary account under human review, so a runbook that copies them inherits whatever that review missed.

Request memoization matches only when the fetch URL and the options object are identical, according to the dev.to walkthrough ^[5]. That rule is what makes the no-store reflex cost more than one thing. Put `{ cache: 'no-store' }` on the layout's fetch and leave the page's untouched, and the two call sites stop sharing a key, so the second one goes to the network as well ^[16].

The worked example in the piece is a layout and a page fetching the same user endpoint, where one request fires during server rendering; without memoization, a layout plus three children calling `/api/user` would fire four ^[10]. Three calls avoided out of four is a 75 percent reduction inside that render ^[15].

A fetch checks the memoization cache, then the data cache, then the network, and populates both on the way back ^[6]. Memoization resets once the server has sent its HTML response ^[4].

Two of the four layers do not answer to server code at all. The full route cache holds HTML prerendered at build time and skips server rendering entirely ^[8]. The router cache lives on the client ^[3], and its static window is ten times its dynamic one ^[14]. A revalidate call runs on the server ^[7], while the copy in the browser expires on its own 30-second or 5-minute timer ^[17].

The performance story stays an assertion in this article. It says the reflex collapses performance ^[2], and that teams both over-invalidate, wasting CPU, and under-invalidate, serving stale data ^[11]. The piece discloses that it "was written with the assistance of AI, under human supervision and review" ^[12]. The published text also breaks off mid-sentence at "The data cache is opt-in by default for GET req" ^[13].

In my view the descriptions of how each layer works earn more trust than the causal claim, because each one can be checked against a running app: render a layout and a page that fetch the same URL, watch the origin's access log, then change one options object and watch it again.

For any of this to transfer to your app, the data loading has to go through fetch. Both server-side layers are described as keyed on a URL and an options object ^[5]^[7], so an ORM call or a direct database driver gives neither layer anything to key on ^[18].

What to watch

Whether anyone publishes origin request counts and server CPU before and after the no-store reflex on a real route.
Whether other write-ups reproduce the 30-second and 5-minute router cache windows or report different values.
Whether the data cache default for GET requests is stated in full in a revised version of the article.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[7]
The data cache persists fetch responses across requests on the server, keyed by URL and options, until the developer invalidates it with revalidatePath, revalidateTag, or a time-based revalidation window.
ReportedSupported2 sources— sign in to open View cited source
[3]
Next.js uses four independent caching layers: request memoization (render-scoped), the data cache (server-persistent), the full route cache (build-time HTML), and the router cache (client-navigation).
ReportedSupportedView cited source
[4]
Request memoization deduplicates identical fetch calls within a single React render pass; the memoization scope is the render tree, and after the server sends the HTML response the memoization cache resets, so the next request starts with an empty memoization layer.
ReportedSupportedView cited source
[5]
Request memoization is automatic and not configured by developers; the only requirement is that the fetch URL and options object match exactly.
ReportedSupportedView cited source
[6]
The memoization layer sits between the component and the data cache: when a component calls fetch, Next.js checks the memoization cache, then the data cache, and on a data cache miss executes the network request and populates both caches.
ReportedSupportedView cited source
[8]
The full route cache stores prerendered static HTML pages at build time and bypasses server rendering entirely.
ReportedSupportedView cited source
[9]
The router cache remembers client-side navigated route payloads for 30 seconds on dynamic routes and 5 minutes on static routes, to speed up back and forward navigation.
ReportedSupportedView cited source
[10]
In the article's example, a layout and a page both fetch the same user endpoint and only one network request fires during server-side rendering; without memoization, a layout and three child components all fetching /api/user would fire four identical requests.
ReportedSupportedView cited source
[12]
The article states that it "was written with the assistance of AI, under human supervision and review".
ReportedSupportedView cited source
[13]
The published text breaks off mid-sentence at "The data cache is opt-in by default for GET req".
ReportedSupportedView cited source
[14]
The static router cache window is ten times the dynamic one.
DerivedSupported1 source— sign in to open
[15]
In the article's four-component example, memoization avoids three of four identical network calls, a 75 percent reduction within that render.
DerivedSupported1 source— sign in to open
[16]
Because the memoization key is the fetch URL plus the options object, adding a cache option at one call site and not another means two fetches of the same URL no longer share a memoized response within one render, and the second call proceeds to the network.
DerivedSupported1 source— sign in to open
[17]
revalidatePath and revalidateTag act on the server-side data cache, so they do not shorten the router cache windows held in the client.
DerivedSupported1 source— sign in to open
[18]
Both server-side layers are keyed on a URL and an options object, so a data path that never passes through fetch, such as an ORM call or a direct database driver, has no key in either layer.
DerivedSupported1 source— sign in to open
[1]
A dev.to article argues that most Next.js caching problems stem from treating four distinct caching mechanisms as a single black box, and that the root cause of the resulting bugs is conceptual rather than a framework quirk.
ReportedInsufficient2 sources— sign in to open View cited source
[2]
The article says teams call fetch, see unexpected stale data, and reach for { cache: 'no-store' } everywhere, and that performance collapses.
ReportedInsufficient2 sources— sign in to open View cited source
[11]
The article says conflating the layers produces stale-data bugs and performance collapse when teams apply the wrong invalidation strategy, and that understanding the boundaries stops teams over-invalidating (wasting CPU) and under-invalidating (serving stale data).
ReportedInsufficient2 sources— sign in to open View cited source

Sources

Publishers with included, body-backed reporting in this cluster.

dev.to
1 article · September 20, 2026
Next.js Caching Mental Model in 2026: Request Memoization, Data Cache, Full Route Cache, and Router Cache Explained Once and for All

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Try

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

The single account we have, jsmanifest's post on dev.to, is written for someone debugging their own app. It names the four layers, gives the lookup order (memoization first, then the data cache, then the network), and puts the three fetch options side by side: no options caches indefinitely, { next: { revalidate: 60 } } re-fetches in the background, { cache: 'no-store' } skips the data cache. Two consequences follow that the post never states. The memoization key is the URL plus the options object, so adding a cache option at one call site and not the other turns one request into two inside the same render. And both server-side layers are keyed on a fetch, so an ORM query or a direct driver call has nothing for revalidateTag to purge. The post also stops mid-sentence in the data cache section, and it does not say which Next.js versions these lifetimes apply to.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence35

0100

One self-published post, AI-assisted, cut off mid-sentence

Every boundary and lifetime in this story traces to a single dev.to post that discloses AI assistance under human review. The post cites no documentation, release note, or maintainer statement, and the text ends partway through the data cache section, leaving the full route cache and router cache as summary bullets. The internal wobble matters too: the data cache is called 'opt-in by default for GET requests' in one line and an option-free fetch is said to cache indefinitely in the next.

AdoptionInsufficient

No usage or deployment signal

This is an explainer, and it reports no version, no project that adopted the model, and no before-and-after measurement. The four-components-into-one-request example is illustrative code the author wrote, not an observation from a running app.

Hype gap+30

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Entities

build
With CRA out of React's docs, the new project default is a rendering decision
1 publisher
build
Invalidating a cache tag on one Next.js instance leaves the other one serving sold-out stock
1 publisher
build
A CDN country header served Googlebot $14.99 on a page declaring GBP in its structured data
1 publisher
build
A strict CSP killed one form in production, and every monitor stayed green
1 publisher

What happened

Why it matters

What to watch

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Perspective Coverage

Reality