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.

Sign up for GitHub

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

Jump to bottom

[Segment Cache] Prioritize hovered links #74672

Open
wants to merge 4 commits into
base: canary
Choose a base branch
from
Open

[Segment Cache] Prioritize hovered links #74672

wants to merge 4 commits into from

Conversation

acdlite
Copy link
Contributor

@acdlite acdlite commented Jan 8, 2025 •
edited
Loading

Based on

This adds a new internal priority level to the prefetch queue for links that are hovered or touched. The idea is that if a user hovers over a link, they're much more likely to click on it.

The elevated priority is added on mouseenter/touchstart. It is not removed on mouseleave/touchend, because even though the user left the link without navigating to it, the link is still more likely to be navigated to than a link that was never hovered at all.

Because the prefetch queue is last-in-first-out, the highest priority link is whichever link was most recently hovered.

@ijjk
Copy link
Member

ijjk commented Jan 9, 2025 •
edited
Loading

Tests Passed

@ijjk
Copy link
Member

ijjk commented Jan 9, 2025 •
edited
Loading

Stats from current PR

Default Build (Increase detected ⚠️)
General Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover Change
buildDuration 22.1s 20.3s N/A
buildDurationCached 19.2s 16.6s N/A
nodeModulesSize 418 MB 418 MB ⚠️ +375 kB
nextStartRea..uration (ms) 549ms 532ms N/A
Client Bundles (main, webpack) Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover Change
5306-HASH.js gzip 53.4 kB 53.8 kB ⚠️ +447 B
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 240 B 242 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 53.4 kB 53.8 kB ⚠️ +447 B
Legacy Client Bundles (polyfills)
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover 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-on-hover 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-prioritize-on-hover 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-prioritize-on-hover Change
index.html gzip 523 B 523 B ✓
link.html gzip 538 B 537 B N/A
withRouter.html gzip 519 B 520 B N/A
Overall change 523 B 523 B ✓
Edge SSR bundle Size Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover Change
edge-ssr.js gzip 128 kB 128 kB N/A
page.js gzip 207 kB 207 kB ⚠️ +248 B
Overall change 207 kB 207 kB ⚠️ +248 B
Middleware size
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover Change
middleware-b..fest.js gzip 669 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 Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover 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 365 kB 366 kB ⚠️ +579 B
app-page-exp..prod.js gzip 129 kB 130 kB ⚠️ +318 B
app-page-tur..prod.js gzip 142 kB 143 kB ⚠️ +316 B
app-page-tur..prod.js gzip 138 kB 139 kB ⚠️ +321 B
app-page.run...dev.js gzip 354 kB 354 kB ⚠️ +539 B
app-page.run..prod.js gzip 126 kB 126 kB ⚠️ +319 B
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 ⚠️ +2.39 kB
build cache Overall increase ⚠️
vercel/next.js canary acdlite/next.js segment-cache-prioritize-on-hover Change
0.pack gzip 2.09 MB 2.09 MB ⚠️ +1.32 kB
index.pack gzip 74.7 kB 74.6 kB N/A
Overall change 2.09 MB 2.09 MB ⚠️ +1.32 kB
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: 9fdf122

@acdlite acdlite force-pushed the segment-cache-prioritize-on-hover branch from 4035fa8 to fb4c490 Compare January 9, 2025 01:17
acdlite added 4 commits January 9, 2025 10:29
@acdlite
This implements support in the Segment Cache for "full" link prefetches,
2c54d64 
typically initiated by passing `prefetch={true}` to a `<Link>`.

The goal of a full prefetch is to request all the data needed for a
navigation, both static and dynamic, so that once the navigation occurs,
the router does not need to fetch any additional data. So, a full
prefetch implicitly instructs the client cache to treat the response as
static, even the dynamic data.

The implementation is largely the same as what we do to support non-
PPR-enabled routes — a request tree is sent to the server describing
which segments are already cached and which ones need to be rendered.
While constructing the request tree, if all the segments are already in
the client cache, the request can be skipped entirely. The main
difference is that a full prefetch will only reuse a cached segment
entry if it does not contain any dynamic holes.
@acdlite
Remove unnecessary re-render on <Link> reveal
b293dd3 
The Link component initiates a prefetch whenever it enters the viewport,
but currently the implementation works by setting an `isVisible` state
to true, rerendering the component, and calling `router.prefetch`
inside a `useEffect` hook. This extra render is not necessary — we can
initiate the prefetch directly inside the IntersectionObserver's
event handler.

The bulk of the changes in this commit involve removing the use of the
`useIntersection` abstraction and inlining the IntersectionObserver
into the Link module. The removal of this indirection will make it
easier to add more sophisticated scheduling improvements, like canceling
the prefetch on viewport exit, and increasing the priority of the
prefetch during hover.

This affects App Router only, not Pages Router.
@acdlite
[Segment Cache] Cancel prefetch on viewport exit
fe7dd71 
We use an IntersectionObserver to prefetch links when they enter the
viewport. This updates the behavior to cancel the prefetch if the
link exits the viewport before it completes.

This can greatly reduce the amount of data transfer caused by
prefetching, however, the impact of this change will depend on the
user's network conditions. The faster the network conditions, the more
likely the link will have already been prefetched by the time the link
exits the screen.

We'll need a different strategy for limiting prefetch data transfer
in fast network conditions, perhaps by tracking and throttling the
overall bitrate.
@acdlite
[Segment Cache] Prioritize hovered links
9fdf122 
This adds a new internal priority level to the prefetch queue for links
that are hovered or touched. The idea is that if a user hovers over a
link, they're much more likely to click on it.

The elevated priority is added on mouseenter/touchstart. It is _not_
removed on mouseleave/touchend, because even though the user left the
link without navigating to it, the link is still more likely to be
navigated to than a link that was never hovered at all.

Because the prefetch queue is last-in-first-out, the highest priority
link is whichever link was most recently hovered.
@acdlite acdlite force-pushed the segment-cache-prioritize-on-hover branch from fb4c490 to 9fdf122 Compare January 9, 2025 15:30
@acdlite acdlite requested review from ztanner and lubieowoce January 9, 2025 18:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ztanner ztanner Awaiting requested review from ztanner

@lubieowoce lubieowoce Awaiting requested review from lubieowoce

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
created-by: Next.js team PRs by the Next.js team. tests type: next
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@acdlite @ijjk