Generate per-segment responses for any static page #73945
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
acdlite
force-pushed
the
segment-cache-support-for-any-static-page
branch
from
f61f5ab to
7211398
Compare
Tests Passed |
Stats from current PRDefault Build (Increase detected
|
| vercel/next.js canary | acdlite/next.js segment-cache-support-for-any-static-page | Change | |
|---|---|---|---|
| buildDuration | 20.7s | 18.6s | N/A |
| buildDurationCached | 17.6s | 14.9s | N/A |
| nodeModulesSize | 410 MB | 410 MB | |
| nextStartRea..uration (ms) | 526ms | 522ms | N/A |
Client Bundles (main, webpack)
| vercel/next.js canary | acdlite/next.js segment-cache-support-for-any-static-page | Change | |
|---|---|---|---|
| 1187-HASH.js gzip | 51.4 kB | 51.4 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.1 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-support-for-any-static-page | 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-support-for-any-static-page | 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-support-for-any-static-page | Change | |
|---|---|---|---|
| _buildManifest.js gzip | 749 B | 746 B | N/A |
| Overall change | 0 B | 0 B | ✓ |
Rendered Page Sizes
| vercel/next.js canary | acdlite/next.js segment-cache-support-for-any-static-page | Change | |
|---|---|---|---|
| index.html gzip | 524 B | 523 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 Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-support-for-any-static-page | Change | |
|---|---|---|---|
| edge-ssr.js gzip | 128 kB | 128 kB | N/A |
| page.js gzip | 204 kB | 204 kB | |
| Overall change | 204 kB | 204 kB |
Middleware size
| vercel/next.js canary | acdlite/next.js segment-cache-support-for-any-static-page | Change | |
|---|---|---|---|
| middleware-b..fest.js gzip | 670 B | 667 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-support-for-any-static-page | 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 | 324 kB | 324 kB | N/A |
| app-page-exp..prod.js gzip | 128 kB | 128 kB | N/A |
| app-page-tur..prod.js gzip | 141 kB | 141 kB | N/A |
| app-page-tur..prod.js gzip | 136 kB | 136 kB | N/A |
| app-page.run...dev.js gzip | 314 kB | 314 kB | N/A |
| app-page.run..prod.js gzip | 124 kB | 124 kB | N/A |
| app-route-ex...dev.js gzip | 37.4 kB | 37.4 kB | ✓ |
| app-route-ex..prod.js gzip | 25.5 kB | 25.5 kB | ✓ |
| app-route-tu..prod.js gzip | 25.5 kB | 25.5 kB | ✓ |
| app-route-tu..prod.js gzip | 25.3 kB | 25.3 kB | ✓ |
| app-route.ru...dev.js gzip | 39 kB | 39 kB | ✓ |
| app-route.ru..prod.js gzip | 25.3 kB | 25.3 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.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 | N/A |
| Overall change | 280 kB | 280 kB | ✓ |
build cache Overall increase ⚠️
| vercel/next.js canary | acdlite/next.js segment-cache-support-for-any-static-page | Change | |
|---|---|---|---|
| 0.pack gzip | 2.05 MB | 2.08 MB | |
| index.pack gzip | 72.7 kB | 74.5 kB | |
| Overall change | 2.12 MB | 2.15 MB |
Diff details
Diff for edge-ssr.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
Diff for server.runtime.prod.js
Diff too large to display
acdlite
force-pushed
the
segment-cache-support-for-any-static-page
branch
from
7211398 to
42ee6a9
Compare
acdlite
force-pushed
the
segment-cache-support-for-any-static-page
branch
from
42ee6a9 to
a96d7df
Compare
ztanner
approved these changes
Dec 17, 2024
| @@ -1,5 +1,6 @@ | |||
| module.exports = { | |||
| experimental: { | |||
| ppr: true, | |||
| clientSegmentCache: true, | |||
There was a problem hiding this comment.
Just curious, but why are we only enabling it for this PPR test?
There was a problem hiding this comment.
It's just temporary so the per-segment-prefetching.test.ts tests still work. I'm just going to delete that test file in an upcoming PR, since we have plenty of coverage via the e2e tests now, and then I can turn this flag off again. I figured it's fine to turn it on here temporarily because the other tests in this directory are fairly basic smoke tests.
This was an oversight on my part when I originally implemented the per- segment prefetches. `onError` needs to return an error digest.
Originally I gated per-segment prefetch generation on the PPR flag, because I thought the client Segment Cache would require PPR to be enabled on the server. However, since then the strategy has evolved and I do think we can roll out the Segment Cache independently of PPR. Dynamic pages without PPR won't be able to take full advantage of the Segment Cache, but if the page is fully static then there's no reason we can't implement all the same behavior. So during per-segment prerendering, I've changed the feature condition to check for the `clientSegmentCache` flag instead of the PPR one.
acdlite
force-pushed
the
segment-cache-support-for-any-static-page
branch
from
a96d7df to
3b7ce78
Compare
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.
Originally I gated per-segment prefetch generation on the PPR flag, because I thought the client Segment Cache would require PPR to be enabled on the server. However, since then the strategy has evolved and I do think we can roll out the Segment Cache independently of PPR.
Dynamic pages without PPR won't be able to take full advantage of the Segment Cache, but if the page is fully static then there's no reason we can't implement all the same behavior.
So during per-segment prerendering, I've changed the feature condition to check for the
clientSegmentCacheflag instead of the PPR one.Additionally, when I broadened the feature check, a failing test revealed that I neglected to set up error digest decoding correctly, so the first commit in this stack fixes that.