Next.js Caching Deep Dive — fetch, Route, and Router Cache

Four layers, not one

Next.js caches at four levels: the fetch/Request Memoization layer, the Data Cache (persistent), the Full Route Cache (rendered HTML), and the client Router Cache. Stale-data bugs almost always come from confusing which layer served the response. Name the layer before debugging.

Data Cache defaults

In Next 16, fetch requests are cached by default in static routes and opt-in elsewhere. Use cache: no-store for user-specific data, and time-based revalidate (e.g. 3600) for semi-static content like pricing or docs. Tag-based revalidateTag is the precision tool — tag product queries by category and invalidate surgically on CMS publishes.

Route cache and dynamism

Anything dynamic (cookies, headers, searchParams) opts its route out of static rendering. One dynamic API call in a layout poisons the whole subtree — push dynamic reads to leaves or split routes. generateStaticParams plus dynamicParams control the SSG/SSR mix per segment.

Router cache gotchas

The client caches visited routes for instant back-navigation, which means mutations must call router.refresh() or the UI shows pre-mutation data. Pair every server action that changes data with either revalidatePath or revalidateTag — pick tags for precision, paths for simplicity.

Related: our deployment checklist (/docs/nextjs-deployment-checklist).