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] Prioritize route trees over segments #75213

Merged
merged 1 commit into from
Jan 23, 2025

Conversation

acdlite
Copy link
Contributor

@acdlite acdlite commented Jan 23, 2025

When processing the prefetch queue, we should prioritize fetching the route trees for all the links before we fetch any of the segments.

The reason the route tree is more important is because it tells us the structure of the target page; from this alone, we can determine which segments are already cached and skip them during the navigation. Whereas if the route tree is missing at the time of the navigation, we cannot instruct the server to skip over prefetched segments, because we don't know which ones to skip.

To implement this, I added a phase property to the PrefetchTask type. This is essentially a secondary priority field that changes as the task progresses. There are two phases: RouteTree and Segments. Any task in the RouteTree phase has higher priority than tasks in the Segments phase.

Another way to implement this would be to add a secondary queue for segment prefetches. This would require reference counting to clean up segments when there are no more tasks that depend on them. The ref count could also be used as an additional prioritization heuristic: shared layouts with many dependent tasks could be prioritized over segments with fewer. However, I'm not sure the benefits are worth the extra code/complexity, so I'm starting with this simpler approach.

When processing the prefetch queue, we should prioritize fetching the
route trees for all the links before we fetch any of the segments.

The reason the route tree is more important is because it tells us the
structure of the target page; from this alone, we can determine which
segments are already cached and skip them during the navigation.
Whereas if the route tree is missing at the time of the navigation, we
cannot instruct the server to skip over prefetched segments, because we
don't know which ones to skip.

To implement this, I added a `phase` property to the PrefetchTask type.
This is essentially a secondary priority field that changes as the task
progresses. There are two phases: `RouteTree` and `Segments`. Any task
in the `RouteTree` phase has higher priority than tasks in the
`Segments` phase.

Another way to implement this would be to add a secondary queue for
segment prefetches. This would require reference counting to clean up
segments when there are no more tasks that depend on them. The ref count
could also be used as an additional prioritization heuristic: shared
layouts with many dependent tasks could be prioritized over segments
with fewer. However, I'm not sure the benefits are worth the extra
code/complexity, so I'm starting with this simpler approach.
@ijjk
Copy link
Member

ijjk commented Jan 23, 2025

Tests Passed

@ijjk
Copy link
Member

ijjk commented Jan 23, 2025

Stats from current PR

Default Build (Increase detected ⚠️)
General Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-prioritize-route-tree Change
buildDuration 21.1s 19s N/A
buildDurationCached 18.2s 15.4s N/A
nodeModulesSize 419 MB 419 MB ⚠️ +30.8 kB
nextStartRea..uration (ms) 478ms 475ms N/A
Client Bundles (main, webpack)
vercel/next.js canary acdlite/next.js segment-cache-prioritize-route-tree Change
5306-HASH.js gzip 54.1 kB 54.1 kB N/A
8276.HASH.js gzip 169 B 168 B N/A
8377-HASH.js gzip 5.46 kB 5.46 kB N/A
bccd1874-HASH.js gzip 52.9 kB 52.9 kB N/A
framework-HASH.js gzip 57.5 kB 57.5 kB N/A
main-app-HASH.js gzip 240 B 242 B N/A
main-HASH.js gzip 34.6 kB 34.6 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-prioritize-route-tree 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-prioritize-route-tree 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.59 kB 4.58 kB N/A
index-HASH.js gzip 268 B 268 B
link-HASH.js gzip 2.35 kB 2.35 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-prioritize-route-tree Change
_buildManifest.js gzip 748 B 747 B N/A
Overall change 0 B 0 B
Rendered Page Sizes
vercel/next.js canary acdlite/next.js segment-cache-prioritize-route-tree Change
index.html gzip 523 B 522 B N/A
link.html gzip 538 B 537 B N/A
withRouter.html gzip 520 B 520 B
Overall change 520 B 520 B
Edge SSR bundle Size
vercel/next.js canary acdlite/next.js segment-cache-prioritize-route-tree Change
edge-ssr.js gzip 129 kB 129 kB N/A
page.js gzip 209 kB 209 kB N/A
Overall change 0 B 0 B
Middleware size
vercel/next.js canary acdlite/next.js segment-cache-prioritize-route-tree 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.3 kB 31.3 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-prioritize-route-tree 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 376 kB 376 kB N/A
app-page-exp..prod.js gzip 131 kB 131 kB N/A
app-page-tur..prod.js gzip 144 kB 144 kB N/A
app-page-tur..prod.js gzip 140 kB 140 kB N/A
app-page.run...dev.js gzip 364 kB 364 kB N/A
app-page.run..prod.js gzip 127 kB 127 kB N/A
app-route-ex...dev.js gzip 37.6 kB 37.6 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.9 kB 21.9 kB
pages.runtim...dev.js gzip 27.7 kB 27.7 kB
pages.runtim..prod.js gzip 21.9 kB 21.9 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-prioritize-route-tree Change
0.pack gzip 2.1 MB 2.1 MB N/A
index.pack gzip 75.4 kB 75.7 kB ⚠️ +292 B
Overall change 75.4 kB 75.7 kB ⚠️ +292 B
Diff details
Diff for 5306-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

Commit: d870c86

@acdlite acdlite merged commit 4f52390 into vercel:canary Jan 23, 2025
108 checks passed
@github-actions github-actions bot added the locked label Feb 7, 2025
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 7, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants