[Segment Cache] Background segment revalidation #74057
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Stats from current PRDefault Build (Increase detected
|
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| buildDuration | 23.8s | 21.9s | N/A |
| buildDurationCached | 20.6s | 18.2s | N/A |
| nodeModulesSize | 417 MB | 418 MB | |
| nextStartRea..uration (ms) | 567ms | 598ms | N/A |
Client Bundles (main, webpack) Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| 1187-HASH.js gzip | 52.6 kB | 53.2 kB | |
| 8276.HASH.js gzip | 169 B | 168 B | N/A |
| 8377-HASH.js gzip | 5.44 kB | 5.44 kB | N/A |
| bccd1874-HASH.js gzip | 53 kB | 53 kB | N/A |
| framework-HASH.js gzip | 57.5 kB | 57.5 kB | N/A |
| main-app-HASH.js gzip | 232 B | 235 B | N/A |
| main-HASH.js gzip | 34.1 kB | 34.1 kB | N/A |
| webpack-HASH.js gzip | 1.71 kB | 1.71 kB | N/A |
| Overall change | 52.6 kB | 53.2 kB |
Legacy Client Bundles (polyfills)
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| polyfills-HASH.js gzip | 39.4 kB | 39.4 kB | ✓ |
| Overall change | 39.4 kB | 39.4 kB | ✓ |
Client Pages
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| _app-HASH.js gzip | 193 B | 193 B | ✓ |
| _error-HASH.js gzip | 193 B | 193 B | ✓ |
| amp-HASH.js gzip | 512 B | 510 B | N/A |
| css-HASH.js gzip | 343 B | 342 B | N/A |
| dynamic-HASH.js gzip | 1.84 kB | 1.84 kB | ✓ |
| edge-ssr-HASH.js gzip | 265 B | 265 B | ✓ |
| head-HASH.js gzip | 363 B | 362 B | N/A |
| hooks-HASH.js gzip | 393 B | 392 B | N/A |
| image-HASH.js gzip | 4.57 kB | 4.57 kB | N/A |
| index-HASH.js gzip | 268 B | 268 B | ✓ |
| link-HASH.js gzip | 2.35 kB | 2.34 kB | N/A |
| routerDirect..HASH.js gzip | 328 B | 328 B | ✓ |
| script-HASH.js gzip | 397 B | 397 B | ✓ |
| withRouter-HASH.js gzip | 323 B | 326 B | N/A |
| 1afbb74e6ecf..834.css gzip | 106 B | 106 B | ✓ |
| Overall change | 3.59 kB | 3.59 kB | ✓ |
Client Build Manifests
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 749 B | 747 B | N/A |
| Overall change | 0 B | 0 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| index.html gzip | 523 B | 524 B | N/A |
| link.html gzip | 538 B | 538 B | ✓ |
| withRouter.html gzip | 519 B | 520 B | N/A |
| Overall change | 538 B | 538 B | ✓ |
Edge SSR bundle Size Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| edge-ssr.js gzip | 128 kB | 128 kB | N/A |
| page.js gzip | 206 kB | 206 kB | |
| Overall change | 206 kB | 206 kB |
Middleware size
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| middleware-b..fest.js gzip | 668 B | 669 B | N/A |
| middleware-r..fest.js gzip | 155 B | 156 B | N/A |
| middleware.js gzip | 31.2 kB | 31.2 kB | N/A |
| edge-runtime..pack.js gzip | 844 B | 844 B | ✓ |
| Overall change | 844 B | 844 B | ✓ |
Next Runtimes Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| 274-experime...dev.js gzip | 322 B | 322 B | ✓ |
| 274.runtime.dev.js gzip | 314 B | 314 B | ✓ |
| app-page-exp...dev.js gzip | 364 kB | 365 kB | |
| app-page-exp..prod.js gzip | 129 kB | 129 kB | |
| app-page-tur..prod.js gzip | 142 kB | 142 kB | |
| app-page-tur..prod.js gzip | 138 kB | 138 kB | |
| app-page.run...dev.js gzip | 352 kB | 353 kB | |
| app-page.run..prod.js gzip | 125 kB | 126 kB | |
| app-route-ex...dev.js gzip | 37.5 kB | 37.5 kB | ✓ |
| app-route-ex..prod.js gzip | 25.6 kB | 25.6 kB | ✓ |
| app-route-tu..prod.js gzip | 25.6 kB | 25.6 kB | ✓ |
| app-route-tu..prod.js gzip | 25.4 kB | 25.4 kB | ✓ |
| app-route.ru...dev.js gzip | 39.2 kB | 39.2 kB | ✓ |
| app-route.ru..prod.js gzip | 25.4 kB | 25.4 kB | ✓ |
| pages-api-tu..prod.js gzip | 9.69 kB | 9.69 kB | ✓ |
| pages-api.ru...dev.js gzip | 11.6 kB | 11.6 kB | ✓ |
| pages-api.ru..prod.js gzip | 9.68 kB | 9.68 kB | ✓ |
| pages-turbo...prod.js gzip | 21.7 kB | 21.7 kB | ✓ |
| pages.runtim...dev.js gzip | 27.5 kB | 27.5 kB | ✓ |
| pages.runtim..prod.js gzip | 21.7 kB | 21.7 kB | ✓ |
| server.runti..prod.js gzip | 916 kB | 916 kB | ✓ |
| Overall change | 2.45 MB | 2.45 MB |
build cache Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-background-revalidation | Change | |
|---|---|---|---|
| 0.pack gzip | 2.08 MB | 2.08 MB | |
| index.pack gzip | 74.2 kB | 74.8 kB | |
| Overall change | 2.16 MB | 2.16 MB |
Diff details
Diff for 1187-HASH.js
Diff too large to display
Diff for main-HASH.js
Diff too large to display
Diff for app-page-exp..ntime.dev.js
Diff too large to display
Diff for app-page-exp..time.prod.js
Diff too large to display
Diff for app-page-tur..time.prod.js
Diff too large to display
Diff for app-page-tur..time.prod.js
Diff too large to display
Diff for app-page.runtime.dev.js
Diff too large to display
Diff for app-page.runtime.prod.js
Diff too large to display
acdlite
force-pushed
the
segment-cache-background-revalidation
branch
from
5500fd3 to
4dea044
Compare
acdlite
force-pushed
the
segment-cache-background-revalidation
branch
2 times, most recently
from
d41b860 to
02e5df4
Compare
Tests Passed |
acdlite
force-pushed
the
segment-cache-background-revalidation
branch
5 times, most recently
from
7abc786 to
1c4e10c
Compare
ztanner
approved these changes
Jan 6, 2025
acdlite
force-pushed
the
segment-cache-background-revalidation
branch
from
1c4e10c to
23a5442
Compare
This was referenced Jan 8, 2025
PrefetchSubtaskResult is a type used to spawn an non-blocking async task while also providing a promise that represents when the task is complete, so that the scheduler can limit the number of concurrent network requests. This updates the type to also include a generic `value` field, so the task can return additional data to the caller. This must be separate from the `closed` field so that the caller can unwrap it before the entire operation has completed. For example, the `value` field will usually represent a streaming result (like a Flight promise) that resolves immediately, whereas the `closed` field only resolves when the stream is complete. No behavior changes in this commit. I'll use this to implement cache revalidation in the following steps.
This implements background revalidation of partial segment entries in
the client Segment Cache.
Until this PR, entries were never replaced in the Segment Cache, they
were only evicted upon becoming stale, or if the LRU overflowed. But
there are cases where we'll want to replace an existing entry with a
new one; for example, if the current segment has more dynamic holes
than the new one.
Most commonly this happens when multiple fetching strategies are mixed
within the same app. For example: when a shared layout belongs to both
a PPR-enabled route and a non-PPR enabled route, the layout data might
be omitted when prefetching the non-PPR enabled route, if it's wrapped
in a loading boundary. But that shouldn't prevent it from being
included when prefetching the route that has PPR enabled.
(Another example is when a shared layout is prefetched both on viewport
entry and also via `<Link prefetch={true}>`. A viewport prefetch will
only include the static data, but prefetch={true} includes both the
static and the dynamic.
`<Link prefetch={true}>` is not yet implemented by the Segment Cache but
it will use a similar background revalidation strategy as the one
implemented in this PR.)
acdlite
force-pushed
the
segment-cache-background-revalidation
branch
from
23a5442 to
df01ab7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements background revalidation of partial segment entries in the client Segment Cache.
Until this PR, entries were never replaced in the Segment Cache, they were only evicted upon becoming stale, or if the LRU overflowed. But there are cases where we'll want to replace an existing entry with a new one; for example, if the current segment has more dynamic holes than the new one.
Most commonly this happens when multiple fetching strategies are mixed within the same app. For example: when a shared layout belongs to both a PPR-enabled route and a non-PPR enabled route, the layout data might be omitted when prefetching the non-PPR enabled route, if it's wrapped in a loading boundary. But that shouldn't prevent it from being included when prefetching the route that has PPR enabled.
(Another example is when a shared layout is prefetched both on viewport entry and also via
<Link prefetch={true}>. A viewport prefetch will only include the static data, butprefetch={true}includes both the static and the dynamic.<Link prefetch={true}>is not yet implemented by the Segment Cache but it will use a similar background revalidation strategy as the one implemented in this PR.)