The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Next.js 15, server-side fetch is not persistently cached by default. To cache data across requests, opt in with cache: 'force-cache' or set a revalidation interval with next.revalidate; use cache: 'no-store' when each request must fetch current data. That policy affects only one layer of a system that also includes request memoization, the Full Route Cache, and the client-side Router Cache.
Start by identifying which cache is involved
Next.js has four distinct cache mechanisms. They store different things and operate over different lifetimes, so diagnosing an issue as “the cache” can lead to changing the wrong setting.
| Layer | What it holds | Scope or lifetime |
|---|---|---|
| Request memoization | Results of repeated eligible GET calls during rendering |
One render/request lifecycle; it does not persist across incoming requests |
| Data Cache | Cached data fetched by the server | Can persist across incoming requests until revalidation or opting out |
| Full Route Cache | Rendered server output for a route | Applies to server-rendered route output, rather than being the store for fetched data itself |
| Router Cache | Route payloads used for client-side navigation | Held in client memory and cleared on a full page refresh |
For example, two matching fetches during one render may be deduplicated by request memoization without being stored for the next visitor. Persistent reuse of fetched data is a Data Cache decision. A cached route response and a client navigation payload are separate concerns again.
Recommended Free Tools
Choose a fetch policy based on freshness
Decide for each data source whether its response can be reused across incoming requests, how quickly it must become fresh, and whether it is specific to the current user. In Next.js 15, do not assume a server-side fetch is persistently cached unless you explicitly select a policy.
#1 Best Overall
Cache data until it is invalidated
Use cache: 'force-cache' when the response can be reused and you want to opt into persistence:
const products = await fetch('https://example.com/api/products', {
cache: 'force-cache',
})This is a policy choice, not a claim that the source data never changes. If updates must appear, plan a revalidation or invalidation mechanism as well.
Revalidate after a chosen interval
Use next.revalidate when data may be reused for a limited period and a time-based freshness policy fits the content:
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteconst posts = await fetch('https://example.com/api/posts', {
next: { revalidate: 3600 },
})The value shown is an example interval in seconds, not a universal recommendation. Set the interval to match how quickly the content needs to become fresh. Time-based revalidation can serve stale data while refreshing it in the background, so it is appropriate only when that temporary staleness is acceptable.
Rank #2
Fetch from the source for each incoming request
Use cache: 'no-store' when each request should fetch current data from its source, including data that is user-specific or otherwise unsuitable for shared persistent reuse:
const account = await fetch('https://example.com/api/account', {
cache: 'no-store',
})Make the freshness requirement explicit rather than relying on defaults. A response that must be current for a particular user should not accidentally become a shared cached response.
Invalidate data when the cause of change is known
Use a time interval for data that changes independently and can tolerate stale-while-revalidate behavior. When an event such as a CMS update or mutation tells you what changed, invalidate the affected paths or tagged data instead.
Free tools Windows power users keep installed
One-click scans. No signup required.
Revalidate affected paths
Use revalidatePath when a known update should refresh a route path:
revalidatePath('/articles')This suits an update whose impact is tied to a page or route. Identify the paths that depend on the changed content rather than invalidating unrelated routes.
Revalidate related data by tag
Use revalidateTag when multiple fetches represent a data group that changes together. Assign tags according to meaningful data relationships, then invalidate the relevant group when it changes:
// Attach a tag to a related fetch:
const articles = await fetch('https://example.com/api/articles', {
next: { tags: ['articles'] },
})
// Invalidate that tagged data after an update:
revalidateTag('articles')Tags are most useful when they reflect the domain data that changes together; overly broad tags can invalidate more cached data than the update requires.
Check route-wide configuration when fetch behavior surprises you
Route segment settings such as dynamic, revalidate, and fetchCache can establish broader policy for a page, layout, or Route Handler. Individual fetch settings and nested route configuration can affect the effective behavior, so inspect the full route tree before concluding that a single request option explains a route’s freshness.
A shorter revalidation interval in a child segment or on an individual request can make that part of a route refresh more frequently. Treat segment configuration as a broad policy layer, then verify that local fetch decisions are consistent with it.
Account for the Next.js 15 default changes
Next.js 15 changed defaults that can make an upgraded application behave differently from an earlier version. Server-side fetch is no longer persistently cached by default. GET Route Handler responses and the client Router Cache also changed from cached by default to uncached by default.
If a route or navigation now appears fresher than before, check whether the application depended on those earlier defaults. Set the intended data policy explicitly and confirm behavior against the specific Next.js version in use; do not carry migration assumptions forward without checking them.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsUse streaming to improve progressive delivery, not as a cache policy
When server data work is slow, loading.js or Suspense boundaries can let Next.js stream available parts of a page while slower work continues. Place boundaries around the portions that can wait so the rest of the page can be delivered progressively.
Streaming is a rendering strategy, not persistent data caching. It can change when users see parts of a response, but it does not by itself make fetched data reusable across requests or prove that total execution time is lower.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Plan cache storage for self-hosted, multi-instance deployments
For a self-hosted application running in several containers or instances, check where cached data is stored and whether that storage is durable and shared in the way the deployment needs. Per-instance storage can mean that instances do not observe the same cached state; storage that is not durable may not survive restarts or deployments.
The right topology depends on the deployment. Evaluate whether cache storage is shared across instances, persists for the required lifetime, and adds an operational burden the team can support. Configure a shared or durable arrangement when consistency across instances or persistence across restarts is required; there is no single universally best provider.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
A practical policy checklist
- Identify whether the issue concerns render-lifecycle memoization, persistent fetched data, rendered route output, or client navigation payloads.
- For each data source, decide whether it can be reused across requests and whether stale data is acceptable.
- Use
force-cachefor explicitly reusable data, a finitenext.revalidateinterval when time-based freshness fits, orno-storewhen each request must fetch current data. - Choose path or tag invalidation when a known update identifies which route or data group changed.
- Review route segment settings alongside individual fetch options, especially after upgrading from an earlier Next.js version.
- Use streaming boundaries for progressive delivery of slow server-rendered content, independently of the data caching policy.
- For self-hosted multi-instance applications, verify cache sharing and durability against the deployment’s actual requirements.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
