Next 16 App Router navigation hangs after _rsc completes, only with cacheComponents

[LGelashvili16]

Summary

Hi everyone. I’m debugging a strange production-only navigation issue after upgrading a Next.js App Router ecommerce project from Next 15 to Next 16.

Stack:

Next.js 16.2.6
React 19
App Router
next-intl
cacheComponents: true
PostgreSQL + Drizzle
Better Auth
pnpm

The same app worked fine on Next 15.
After upgrading to Next 16, some  navigations randomly get stuck in production. The top loader goes almost to the end and stays there. Sometimes the route commits after 30 seconds, sometimes after 1-3 minutes, and sometimes it never commits until I click the link again.
Important detail: the network is not slow.

Example from my navigation debugger:

[nav-debug] link click
href: /categories/printing
from: /

[nav-debug] fetch start
kind: rsc
url: /categories/printing?_rsc=...

[nav-debug] fetch done
kind: rsc
status: 200
ms: 18

[nav-debug] navigation still not committed
currentPath: /
expectedPath: /categories/printing
likelyRouterOrHydrationIssue: true

... about 48 seconds later ...

[nav-debug] commit
pathname: /categories/printing

I also checked the Network tab. _rsc finishes quickly and /_next/static JS/CSS chunks are not pending. So it does not look like DB latency, server latency, proxy latency, or slow chunk loading.

The affected route was showing as Partial Prerendered in the production build:
◐ /[locale]/categories/[...categorySlug]

When I temporarily disabled cacheComponents: true and commented out "use cache", cacheTag, and cacheLife, the build

changed the routes to dynamic:
ƒ /[locale]/categories/[...categorySlug]

After that, navigation worked normally again.

I also tried changing experimental.staleTimes, but Next warned about minimum values, and it did not solve the issue.
So my current conclusion is that this is related to Next 16 Cache Components / PPR / client router segment cache behavior. It feels like the RSC response is ready, but the App Router does not commit the transition for a long time.

Questions:
Has anyone else seen App Router navigation hang after upgrading from Next 15 to Next 16?
Is there a known issue with cacheComponents, PPR, or the client router segment cache delaying route commits?
Are there better debugging tools for seeing what the App Router is waiting on after _rsc has already completed?
Any advice would be appreciated. This has been very hard to trace because the server response is fast, but the client route commit is delayed or stuck.

Additional information

No response

Example

No response

[theaditisingh]

Based on your debugging, I would focus on Cache Components / PPR interactions first.

A few things I would test:

1. Create a minimal reproduction with cacheComponents: true enabled and remove next-intl, auth, and database dependencies. If the issue disappears, add them back one by one.

2. Check whether any Server Component, layout, or async boundary is waiting on a promise that is not reflected in the _rsc request timing. The RSC payload may be returned quickly while React is still waiting to resolve another boundary before committing.

3. Compare production builds with and without use cache, cacheTag, and cacheLife. Since disabling them changes the route from Partial Prerendered to Dynamic and removes the issue, that seems like an important signal.

4. Test with the latest Next.js canary release. There have been fixes related to App Router caching, PPR, and client-side navigation behavior between releases.

5. Use React DevTools Profiler and inspect whether hydration or a Suspense boundary is delaying the route commit after the RSC response has completed.

The fact that _rsc completes in ~18 ms but the navigation commit occurs tens of seconds later suggests the bottleneck may be on the client side rather than network or database latency.

If you can provide a minimal reproduction, it would be much easier to determine whether this is an application-level issue or a framework bug.

[LGelashvili16]

Thanks a lot for helpful response. I installed next 16.3.0 canary locally and tested the same navigation flow for around 20 minutes. So far it looks good I haven’t reproduced the long navigation stall yet. Of course that is not enough time to call it fully fixed, but it is a promising signal.