next.js

b9861fd2 - only prefix prefetch cache entries if they vary based on `Next-URL` (#61235)

only prefix prefetch cache entries if they vary based on `Next-URL` (#61235) ### What Prefetches to pages within a shared layout would frequently cache miss despite having the data available. This causes the "instant navigation" behavior (with the 30s/5min TTL) to not be effective on these pages. ### Why In #59861, `nextUrl` was added as a prefetch cache key prefix to ensure multiple interception routes that correspond to the same URL wouldn't clash in the prefetch cache. However this causes a problem in the case where you're navigating between sub-pages. To illustrate the issue, consider the case where you load `/foo`. This will populate the prefetch cache with an entry of `{foo: <PrefetchCacheNode}`. Navigating to `/foo/bar`, with a link that prefetches back to `/foo`, will now result in a new cache node: `{foo: <PrefetchCacheNode>, /foo/bar%/foo: <PrefetchCacheNode>}` (where `Next-URL` is `/foo/bar`). Now we have a cache entry for the full data, as well as a cache entry for a partial prefetch up to the nearest loading boundary. Now when we navigate back to `/foo`, the router will see that it's missing data, and need to lazy-fetch the data triggering the loading boundary. This was especially noticeable in the case where you have a route group with it's own loading.js file because it creates a level of hierarchy in the React tree, and suspending on the data fetch would result in the group's loading boundary to be triggered. In the non-route group scenario, there's still a bug here but it would stall on the data fetch rather than triggering a boundary. ### How In #61794 we conditionally send `Next-URL` as part of the `Vary` header if we detect it could be intercepted. We use this information when creating the prefetch entry to prefix it, in case it corresponds with an intercepted route. Closes NEXT-2193