Next.js 15 overhauled its caching model, reversing defaults and introducing fine-grained control via unstable_cache, tag-based revalidation, and new primitives like connection() and noStore(). Understanding these is critical for building performant, correct applications.
0 / 5 completed
1 / 5
What does unstable_cache do in Next.js 15?
unstable_cache memoizes the result of an async function on the server across multiple requests. You can attach cache tags and set a revalidate TTL, enabling tag-based or time-based invalidation independent of fetch().
2 / 5
You call revalidateTag('products') in a Server Action. What happens?
revalidateTag purges the cache for all entries tagged with the given string. On the next request for any affected page or layout, Next.js re-runs the cached function and stores the fresh result — this is on-demand ISR.
3 / 5
What is the purpose of calling connection() inside a Server Component in Next.js 15?
connection() (formerly unstable_noStore in some betas) explicitly tells Next.js that this component must not be prerendered statically because it depends on the incoming request. It ensures fresh data at request time.
4 / 5
In Next.js 15, fetch(url, { next: { revalidate: 60 } }) sets a 60-second TTL. What changed about fetch caching defaults compared to Next.js 13/14?
Next.js 15 reversed the fetch caching default: fetch calls are no longer cached by default. In 13/14 they were cached by default (cache: 'force-cache'). Now you must explicitly set { next: { revalidate: N } } or cache: 'force-cache' to enable caching.
5 / 5
What does noStore() do when called inside a cached Server Component?
noStore() is the per-invocation escape hatch that marks the component as dynamic. Even if surrounding layouts are static, calling noStore() ensures this component always fetches fresh data and is not stored in Next.js's Full Route Cache.