@tank/nextjs-caching-guide

Next.js stale data occurs when the wrong cache layer is invalidated. The issue must be diagnosed across request memoization, data cache, full route cache, or router cache to determine if the fix belongs in server actions, fetch tags, or route revalidation.

Next.js caching issues are fixed by applying revalidatePath for broad route invalidation or revalidateTag for targeted fetch cache updates. The correct strategy depends on identifying whether the stale content originates from the full route cache or the data cache.

The full route cache stores statically rendered server-side output on the server, while the router cache caches visited route segments on the client. Distinguishing these layers is essential to target the correct source of outdated content or slow renders.

Migrating from unstable_cache to the use cache model involves adopting version-aware directives like cacheLife and cacheTag. This transition aligns caching behavior with Next.js 14-16 updates for more predictable data cache control and revalidation.

Next.js ISR works with self-hosted CDN configurations by utilizing time-based revalidation and custom headers. Debugging cache behavior requires verifying static versus dynamic indicators and logs to ensure the CDN edge cache invalidates correctly.

Next.js fetch cache may not revalidate with router.refresh because it primarily clears the client-side router cache, not the server-side data cache. Fixing this requires server actions utilizing revalidatePath or revalidateTag to purge outdated data.