Router Cache Staleness vs. staleTimes.dynamic: Trade-Off for Navigational Freshness in Next.js 15+

In Next.js 15+ App Router, users navigating back to a previously visited route may see outdated list items or timestamps instead of fresh server-rendered content. This stems from the Router Cache's per-segment payload storage in the browser session, which serves cached RSC responses on back-forward navigation without contacting the server. The concrete constraint balances instant navigational performance against data freshness when routes are revisited after mutations or time-sensitive updates.

In Next.js 15, dynamic segments are no longer stale by default, while static segments keep a longer caching window. Link prefetching can populate the Router Cache before user interaction, making staleness visible on first visits. The trade-off favors longer staleTime for navigation speed, or staleTimes.dynamic zero and no-store fetches for fresh payloads at the cost of perceived latency. Documentation does not prescribe a single correct choice, and the interaction between Route Cache, Data Cache, and Router Cache means disabling one layer does not alone ensure fresh output.

• Which routes truly require fresh data on every revisit, and which can tolerate the default stale window without user-visible staleness?
• Does setting staleTimes.dynamic to 0 with selective no-store fetches eliminate stale payloads across all navigation patterns, or does stale-while-revalidate still serve one cached response per window?
• When is it more appropriate to rely on router.refresh() or revalidatePath after mutations rather than tuning staleTimes globally?