[Segment Cache] Add CacheStatus.Empty #73667
Merged
+110
−62
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
acdlite
force-pushed
the
segment-cache-status-empty
branch
2 times, most recently
from
a3b6782 to
42e468d
Compare
Stats from current PRDefault Build (Increase detected
|
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| buildDuration | 18.3s | 16.4s | N/A |
| buildDurationCached | 15.2s | 13.2s | N/A |
| nodeModulesSize | 410 MB | 410 MB | |
| nextStartRea..uration (ms) | 478ms | 482ms | N/A |
Client Bundles (main, webpack)
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| 1187-HASH.js gzip | 50.8 kB | 50.8 kB | N/A |
| 8276.HASH.js gzip | 169 B | 168 B | N/A |
| 8377-HASH.js gzip | 5.36 kB | 5.36 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 | 233 B | 235 B | N/A |
| main-HASH.js gzip | 34 kB | 34 kB | N/A |
| webpack-HASH.js gzip | 1.71 kB | 1.71 kB | N/A |
| Overall change | 0 B | 0 B | ✓ |
Legacy Client Bundles (polyfills)
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | 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-status-empty | 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.49 kB | 4.49 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-status-empty | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 747 B | 746 B | N/A |
| Overall change | 0 B | 0 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| index.html gzip | 524 B | 522 B | N/A |
| link.html gzip | 539 B | 537 B | N/A |
| withRouter.html gzip | 520 B | 519 B | N/A |
| Overall change | 0 B | 0 B | ✓ |
Edge SSR bundle Size
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| edge-ssr.js gzip | 128 kB | 128 kB | N/A |
| page.js gzip | 203 kB | 203 kB | N/A |
| Overall change | 0 B | 0 B | ✓ |
Middleware size
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| middleware-b..fest.js gzip | 671 B | 666 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
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| 523-experime...dev.js gzip | 322 B | 322 B | ✓ |
| 523.runtime.dev.js gzip | 314 B | 314 B | ✓ |
| app-page-exp...dev.js gzip | 323 kB | 323 kB | N/A |
| app-page-exp..prod.js gzip | 127 kB | 127 kB | N/A |
| app-page-tur..prod.js gzip | 140 kB | 140 kB | N/A |
| app-page-tur..prod.js gzip | 135 kB | 135 kB | N/A |
| app-page.run...dev.js gzip | 313 kB | 313 kB | N/A |
| app-page.run..prod.js gzip | 123 kB | 123 kB | N/A |
| app-route-ex...dev.js gzip | 37.3 kB | 37.3 kB | ✓ |
| app-route-ex..prod.js gzip | 25.4 kB | 25.4 kB | ✓ |
| app-route-tu..prod.js gzip | 25.4 kB | 25.4 kB | ✓ |
| app-route-tu..prod.js gzip | 25.2 kB | 25.2 kB | ✓ |
| app-route.ru...dev.js gzip | 38.9 kB | 38.9 kB | ✓ |
| app-route.ru..prod.js gzip | 25.2 kB | 25.2 kB | ✓ |
| pages-api-tu..prod.js gzip | 9.67 kB | 9.67 kB | ✓ |
| pages-api.ru...dev.js gzip | 11.6 kB | 11.6 kB | ✓ |
| pages-api.ru..prod.js gzip | 9.66 kB | 9.66 kB | ✓ |
| pages-turbo...prod.js gzip | 21.7 kB | 21.7 kB | ✓ |
| pages.runtim...dev.js gzip | 27.4 kB | 27.4 kB | ✓ |
| pages.runtim..prod.js gzip | 21.7 kB | 21.7 kB | ✓ |
| server.runti..prod.js gzip | 916 kB | 916 kB | ✓ |
| Overall change | 1.2 MB | 1.2 MB | ✓ |
build cache Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-status-empty | Change | |
|---|---|---|---|
| 0.pack gzip | 2.05 MB | 2.05 MB | N/A |
| index.pack gzip | 72.2 kB | 73 kB | |
| Overall change | 72.2 kB | 73 kB |
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
Tests Passed |
acdlite
force-pushed
the
segment-cache-status-empty
branch
2 times, most recently
from
dcb5292 to
debb151
Compare
This is a small refactor to allow creating a cache empty entry without also triggering a server request. Currently these are combined into the same phase, because there's no case where one operation happens without the other. However, I need to implement additional prefetching strategies. For example, sometimes a segment's data will already be available as part of a different server response. To support this, I've split the Pending CacheStatus into two separate fields: - Empty: The cache entry has no data, and there's no pending request to fetch it. - Pending: The cache entry has no data, and there _is_ a pending request to fetch it. This is a refactor only, so there should be no change to external behavior.
acdlite
force-pushed
the
segment-cache-status-empty
branch
from
debb151 to
2882abf
Compare
This was referenced Dec 15, 2024
ztanner
approved these changes
Dec 16, 2024
acdlite
added a commit
that referenced
this pull request
Dec 18, 2024
Based on: - #73945 - #73853 - #73667 - #73877 --- This implements support for the Segment Cache in projects/pages where PPR is not enabled. I originally thought the Segment Cache would be tied to the roll out of PPR, because to take full advantage of per-segment caching, you need PPR to generate static shells for each segment. However, as I was investigating how to support the incremental PPR opt-in API, where some pages support PPR and others don't — perhaps just by falling back to the old cache implementation — I realized that there are benefits to per-segment caching even if the requests themselves are not per-segment. For example, when performing a non-PPR-style prefetch, the server diffs the prefetched page against a description of the base page sent by the client. In the old caching implementation, the base tree represented whatever the current page was at the time of the prefetch. In the Segment Cache implementation, we improve on this by telling the server to exclude any shared layouts that are already in the client cache. This ended up requiring more code than I would have preferred, because dynamic server responses and per-segment server responses have differentformats and constraints. However, I realized I was going to have to implement most of this regardless in order to support `<Link prefetch={true}>`, which performs a full dynamic request. Once more of the pieces are settled, we can simplify the implementation by unifying/redesigning some of the data structures, especially FlightRouterState, which has become overloaded with many different concerns. But we need to land some of our experiments first — one reason there's more code than you might expect is because of all the different combinations of features/experiments we need to support simultaneously. While it's likely that PPR will be enabled by default sometime within the next few release cycles, supporting non-PPR projects means we have a pathway to rolling out additional prefetching improvements (like prioritization and cancellation) independently of the PPR release.
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 is a small refactor to allow creating a cache empty entry without also triggering a server request. Currently these are combined into the same phase, because there's no case where one operation happens without the other.
However, I need to implement additional prefetching strategies. For example, sometimes a segment's data will already be available as part of a different server response.
To support this, I've split the Pending CacheStatus into two separate fields:
This is a refactor only, so there should be no change to external behavior.