Renew prefetch cache entry after update from server

[ztanner]

What

When a prefetch cache entry becomes "stale", it'll remain stale until eventually it gets evicted. However during that stale window, the cache is never revalidated, and so instant navigations stop working and data is fetched from origin every navigation.

Why

The lastUsedTime entry on the prefetch cache is currently only updated after the first read. Once it becomes stale, applyFlightData's recursive functions will see that there is no longer a reusable prefetch cache entry, and will trigger a lazy fetch of the new data on every subsequent navigation.

How

This updates prefetch cache handling to always ensure we’re using a fresh or reusable prefetch cache entry. This means that stale prefetch entries will be refreshed on a navigation event. As a result of this, I’ve had to disable one of our tests that relies on this stale cache behavior. It’s not ideal that we’re blocked on the loading boundary when fetching child segment data—ideally we can refactor this to cache the loading component in the CacheNode and copy it over on navigations, similar to how ‘head’ is handled. I’ll work on this in a separate PR.

Note: The new client cache test for this is disabled in PPR for the same reason as the other tests: auto prefetching with PPR navigations is currently loading fresh data rather than reusing the prefetch cache.

Fixes #58969
Fixes #58723
Closes NEXT-1904

[ztanner]

• Renew prefetch cache entry after update from server #61573 👈
• seed prefetch cache with initial page #61535
• only prefix prefetch cache entries if they vary based on Next-URL #61235
• conditionally send Next-URL in Vary response #61794 1 other dependent PR (provide interception rewrites to edge runtime #61414 )
• consolidate prefetch utils & separate build util #61789
• canary

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @ztanner and the rest of your teammates on Graphite

[ijjk]

Tests Passed

[ijjk]

Stats from current PR

Default Build

General

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
buildDuration	14.1s	14.2s	⚠️ +107ms
buildDurationCached	7.4s	8.3s	⚠️ +841ms
nodeModulesSize	196 MB	196 MB	N/A
nextStartRea..uration (ms)	421ms	434ms	N/A

Client Bundles (main, webpack)

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
1068-HASH.js gzip	30.3 kB	30.3 kB	N/A
3f784ff6-HASH.js gzip	53.5 kB	53.5 kB	N/A
4944-HASH.js gzip	5.04 kB	5.03 kB	N/A
8423.HASH.js gzip	181 B	181 B	✓
framework-HASH.js gzip	45.2 kB	45.2 kB	✓
main-app-HASH.js gzip	241 B	241 B	✓
main-HASH.js gzip	32.1 kB	32.1 kB	N/A
webpack-HASH.js gzip	1.7 kB	1.7 kB	✓
Overall change	47.3 kB	47.3 kB	✓

Legacy Client Bundles (polyfills)

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
polyfills-HASH.js gzip	31 kB	31 kB	✓
Overall change	31 kB	31 kB	✓

Client Pages

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
_app-HASH.js gzip	196 B	196 B	✓
_error-HASH.js gzip	184 B	183 B	N/A
amp-HASH.js gzip	503 B	504 B	N/A
css-HASH.js gzip	323 B	324 B	N/A
dynamic-HASH.js gzip	2.5 kB	2.51 kB	N/A
edge-ssr-HASH.js gzip	258 B	259 B	N/A
head-HASH.js gzip	353 B	351 B	N/A
hooks-HASH.js gzip	370 B	370 B	✓
image-HASH.js gzip	4.21 kB	4.2 kB	N/A
index-HASH.js gzip	259 B	259 B	✓
link-HASH.js gzip	2.68 kB	2.67 kB	N/A
routerDirect..HASH.js gzip	313 B	314 B	N/A
script-HASH.js gzip	386 B	385 B	N/A
withRouter-HASH.js gzip	309 B	311 B	N/A
1afbb74e6ecf..834.css gzip	106 B	106 B	✓
Overall change	931 B	931 B	✓

Client Build Manifests

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
_buildManifest.js gzip	485 B	484 B	N/A
Overall change	0 B	0 B	✓

Rendered Page Sizes

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
index.html gzip	529 B	528 B	N/A
link.html gzip	541 B	540 B	N/A
withRouter.html gzip	524 B	522 B	N/A
Overall change	0 B	0 B	✓

Edge SSR bundle Size

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
edge-ssr.js gzip	2.29 kB	2.29 kB	N/A
page.js gzip	2.98 kB	2.98 kB	N/A
Overall change	0 B	0 B	✓

Middleware size

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
middleware-b..fest.js gzip	623 B	626 B	N/A
middleware-r..fest.js gzip	151 B	151 B	✓
middleware.js gzip	466 B	465 B	N/A
edge-runtime..pack.js gzip	839 B	839 B	✓
Overall change	990 B	990 B	✓

Next Runtimes

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
app-page-exp...dev.js gzip	166 kB	166 kB	✓
app-page-exp..prod.js gzip	95.9 kB	95.9 kB	✓
app-page-tur..prod.js gzip	97.6 kB	97.6 kB	✓
app-page-tur..prod.js gzip	92 kB	92 kB	✓
app-page.run...dev.js gzip	136 kB	136 kB	✓
app-page.run..prod.js gzip	90.6 kB	90.6 kB	✓
app-route-ex...dev.js gzip	22 kB	22 kB	✓
app-route-ex..prod.js gzip	14.9 kB	14.9 kB	✓
app-route-tu..prod.js gzip	14.9 kB	14.9 kB	✓
app-route-tu..prod.js gzip	14.6 kB	14.6 kB	✓
app-route.ru...dev.js gzip	21.7 kB	21.7 kB	✓
app-route.ru..prod.js gzip	14.6 kB	14.6 kB	✓
pages-api-tu..prod.js gzip	9.47 kB	9.47 kB	✓
pages-api.ru...dev.js gzip	9.74 kB	9.74 kB	✓
pages-api.ru..prod.js gzip	9.47 kB	9.47 kB	✓
pages-turbo...prod.js gzip	22.1 kB	22.1 kB	✓
pages.runtim...dev.js gzip	22.7 kB	22.7 kB	✓
pages.runtim..prod.js gzip	22.1 kB	22.1 kB	✓
server.runti..prod.js gzip	50.1 kB	50.1 kB	✓
Overall change	927 kB	927 kB	✓

build cache

	vercel/next.js canary	vercel/next.js 02-02-renew_router_cache_after_update_from_server	Change
0.pack gzip	1.49 MB	1.49 MB	N/A
index.pack gzip	104 kB	104 kB	N/A
Overall change	0 B	0 B	✓

Diff details

Diff for 1068-HASH.js

Diff too large to display

Commit: f507d83

[AkifumiSato]

If this pull request is merged, I will close #58997.

[acdlite]

Looks great, thanks for the #DigDeep

[acdlite]

I think is argument is no longer needed? For the same reason you removed it from the PPR implementation

[ztanner]

I think it's still needed but for a more subtle reason -- we set this flag to true specifically for auto prefetches that don't have a reusable cache status. So that means fresh entries technically don't fall into this categorization.

When attempting to remove it I was noticing that once we renewed the stale prefetch, the lazy fetch was never happening, because fillLazyItemsTillLeafWithHead would always hit this condition since there would always be an existing cache node.

For now I'm going to leave it as-is but I'd like to better understand why fillLazyItemsTillLeafWithHead is triggering any lazy fetch behavior rather than fillCacheWithNewSubtreeData.