Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Segment Cache] Skip dynamic request if possible #73540

Merged
merged 1 commit into from
Dec 10, 2024

Conversation

acdlite
Copy link
Contributor

@acdlite acdlite commented Dec 5, 2024

During a navigation, if all the data has been prefetched, and the target route does not contain any dynamic data, then we should skip a request to the server.

This uses the isPartial field I added in the previous PRs to track whether the prefetched data is complete or not.

@ijjk
Copy link
Member

ijjk commented Dec 5, 2024

Tests Passed

@ijjk
Copy link
Member

ijjk commented Dec 5, 2024

Stats from current PR

Default Build (Increase detected ⚠️)
General Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request Change
buildDuration 20.5s 17.6s N/A
buildDurationCached 16.7s 14.6s N/A
nodeModulesSize 409 MB 409 MB ⚠️ +107 kB
nextStartRea..uration (ms) 470ms 451ms N/A
Client Bundles (main, webpack) Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request Change
1187-HASH.js gzip 50.2 kB 50.4 kB ⚠️ +264 B
8276.HASH.js gzip 169 B 168 B N/A
8377-HASH.js gzip 5.3 kB 5.3 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 33.8 kB 33.7 kB N/A
webpack-HASH.js gzip 1.71 kB 1.71 kB N/A
Overall change 50.2 kB 50.4 kB ⚠️ +264 B
Legacy Client Bundles (polyfills)
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request 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-skip-dynamic-request Change
_app-HASH.js gzip 193 B 193 B
_error-HASH.js gzip 193 B 193 B
amp-HASH.js gzip 513 B 511 B N/A
css-HASH.js gzip 343 B 342 B N/A
dynamic-HASH.js gzip 1.84 kB 1.84 kB N/A
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.44 kB 4.43 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 1.75 kB 1.75 kB
Client Build Manifests
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request Change
_buildManifest.js gzip 746 B 747 B N/A
Overall change 0 B 0 B
Rendered Page Sizes
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request Change
index.html gzip 524 B 521 B N/A
link.html gzip 537 B 537 B
withRouter.html gzip 520 B 519 B N/A
Overall change 537 B 537 B
Edge SSR bundle Size
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request 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-skip-dynamic-request Change
middleware-b..fest.js gzip 668 B 666 B N/A
middleware-r..fest.js gzip 155 B 156 B N/A
middleware.js gzip 31 kB 31 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-skip-dynamic-request Change
797-experime...dev.js gzip 322 B 322 B
797.runtime.dev.js gzip 314 B 314 B
app-page-exp...dev.js gzip 322 kB 322 kB N/A
app-page-exp..prod.js gzip 127 kB 127 kB
app-page-tur..prod.js gzip 140 kB 140 kB
app-page-tur..prod.js gzip 135 kB 135 kB
app-page.run...dev.js gzip 312 kB 312 kB N/A
app-page.run..prod.js gzip 122 kB 122 kB
app-route-ex...dev.js gzip 37.1 kB 37.1 kB
app-route-ex..prod.js gzip 25.1 kB 25.1 kB
app-route-tu..prod.js gzip 25.1 kB 25.1 kB
app-route-tu..prod.js gzip 24.9 kB 24.9 kB
app-route.ru...dev.js gzip 38.7 kB 38.7 kB
app-route.ru..prod.js gzip 24.9 kB 24.9 kB
pages-api-tu..prod.js gzip 9.56 kB 9.56 kB
pages-api.ru...dev.js gzip 11.4 kB 11.4 kB
pages-api.ru..prod.js gzip 9.56 kB 9.56 kB
pages-turbo...prod.js gzip 21.3 kB 21.3 kB
pages.runtim...dev.js gzip 27 kB 27 kB
pages.runtim..prod.js gzip 21.3 kB 21.3 kB
server.runti..prod.js gzip 916 kB 916 kB
Overall change 1.72 MB 1.72 MB
build cache Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-skip-dynamic-request Change
0.pack gzip 2.04 MB 2.04 MB ⚠️ +782 B
index.pack gzip 144 kB 146 kB ⚠️ +1.45 kB
Overall change 2.18 MB 2.19 MB ⚠️ +2.23 kB
Diff details
Diff for 1187-HASH.js

Diff too large to display

Diff for main-HASH.js

Diff too large to display

Commit: b40963b

@acdlite acdlite force-pushed the segment-cache-skip-dynamic-request branch from 192f2b7 to 1861f1f Compare December 5, 2024 04:04
@acdlite acdlite marked this pull request as draft December 5, 2024 04:48
@acdlite acdlite force-pushed the segment-cache-skip-dynamic-request branch 5 times, most recently from f8271df to cbc4577 Compare December 6, 2024 18:49
@acdlite acdlite force-pushed the segment-cache-skip-dynamic-request branch from cbc4577 to c973e4b Compare December 7, 2024 16:57
During a navigation, if all the data has been prefetched, and the
target route does not contain any dynamic data, then we should skip
a request to the server.

This uses the `isPartial` field I added in the previous PRs to track
whether the prefetched data is complete or not.
@acdlite acdlite force-pushed the segment-cache-skip-dynamic-request branch from c973e4b to b40963b Compare December 8, 2024 22:28
@acdlite acdlite marked this pull request as ready for review December 9, 2024 03:02
@acdlite acdlite requested a review from ztanner December 9, 2024 03:02
@@ -413,6 +533,11 @@ function finishTaskUsingDynamicDataPayload(
dynamicData: CacheNodeSeedData,
dynamicHead: React.ReactNode
) {
if (!task.needsDynamicRequest) {
// Everything in this subtree is already complete. Bail out.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how come we'd be finishing tasks with dynamic payload, if the task didn't need a dynamic request? Feels like this should have aborted earlier in the stack but maybe I'm misunderstanding it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in practice it never happens but there's nothing in the data structures that prevents it. So it's just defensive.

@acdlite acdlite merged commit eecc5f1 into vercel:canary Dec 10, 2024
86 checks passed
ijjk pushed a commit that referenced this pull request Dec 10, 2024
acdlite added a commit that referenced this pull request Dec 12, 2024
Based on:
- #73540

---

Currently if you navigate to a partially static route, the server will
always start rendering at the first segment that's not present on the
previous page. However, it should really start rendering at the first
*dynamic* segment — if the client has already prefetched a segment, and
it's fully static, there's no reason to render it again during the
dynamic server render.

We can do this by sending a more specific Next-Router-State-Tree request
header. Rather than send a tree that represents the previous route, we
sent the tree of the target route, but with a `refetch` marker added to
the first dynamic segment. (Without the refetch marker, the server would
send back an empty response.) This is determined by diffing against both
the previous route *and* the prefetch cache.

For now, this only works up to the first dynamic segment inside the new
subtree; once the server starts rendering along a path, it renders
everything else along that path. We could improve this in the future to
also omit static segments that appear inside a dynamic layout, though
this would likely require a change to the Next-Router-State-Tree
protocol.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants