Opting Out: Dynamic Rendering and no-store
Force dynamic behavior with cookies, headers, and the no-store directive when caching is wrong.
When Caching Is Wrong
By default, Next.js 15 tries to make your routes static at build time and cache data aggressively. That is great for marketing pages, but wrong for things that must reflect the current request.
- A dashboard showing the logged-in user's data
- A page that reads the request's
cookies()orheaders() - Prices, inventory, or notifications that change every second
This lesson is about opting out of caching: forcing dynamic rendering and disabling fetch caching with no-store.
Static vs Dynamic Rendering
A route is rendered in one of two modes:
- Static: rendered once (at build, or in the background) and the HTML/data is reused for everyone.
- Dynamic: rendered fresh on every request, so it can read per-request input.
Next.js decides automatically. The moment your code touches a Dynamic API (cookies(), headers(), searchParams) or an uncached fetch, the route switches to dynamic. You rarely flip it manually — you opt out of caching and the renderer follows.
All lessons in this course
- The Four Caches: Request, Data, Full Route, and Router
- Time-Based and On-Demand Revalidation Strategies
- Tag-Based Invalidation for Granular Cache Busting
- Opting Out: Dynamic Rendering and no-store