Reuse prefetched next/link cache on hover

[fitiskin]

Describe the feature you'd like to request

Idea: reduce the HTTP requests count that next/link generates when hovering over a link.

My thoughts:

• skip prefetching on hover when the link has already been prefetched (prefetch=true/undefined on viewport)
• do not repeat prefetch on hover after the previous one
• do not call prefetch on hover when the same prefetch request is pending
• there should be a way to disable it completely

Describe the solution you'd like

Respect next/link prefetched cache on hover.

Describe alternatives you've considered

• throttling
• hover duration
• other cache than next/link prefetched

[jettlove]

agree, nobody wants to DDOS their backend

[SukkaW]

I am wondering if this is the intended behavior. Imagine that the user hovers over the link, but not perform the navigate. And then the prefetched data get outdated. So once the user hover again, the data should be re-prefetched by then.

[fitiskin]

Maybe. I wasn't sure if this was not intentional behavior.

I considered this as a feature because of the last point, which changes the behavior of the component and in my opinion needs confirmation from maintainers.

[SukkaW]

Maybe. I wasn't sure if this was not intentional behavior. I can try to make a fix by myself since I already started yesterday.

I considered this as a feature because of the last point, which changes the behavior of the component and in my opinion needs confirmation from maintainers.

Actually, I am considering introducing a 10ms/20ms delay before prefetching (for onMouseEnter only, onTouchStart doesn't need that). This should prevent unwanted prefetches.

[fitiskin]

Actually, I am considering introducing a 10ms/20ms delay before prefetching (for onMouseEnter only, onTouchStart doesn't need that).

@trompx has a similar idea

[ijjk]

Hi, as mentioned by @SukkaW this is intentional since with ISR the content could have been updated since it was prefetched due to being in the viewport so we attempt an additional optimistic prefetch on hover to allow getting fresh content. In most cases this will probably be a 304 which is a very minimal request (the payload body is not sent) and not expensive for the server to handle.

If you aren't leveraging ISR and know the content won't change and would prefer stale content always be used you can disable this under an experimental config already experimental.optimisticClientCache: false

next.js/packages/next/server/config-shared.ts

Line 80 in fa08a17

optimisticClientCache?: boolean

[meotimdihia]

This feature should be documented.

[khuezy]

@ijjk What about the case where the server gets throttled if you instantaneously spam it 10 requests b/c you have 10 Links in the viewport?
It would be better to stagger the requests instead of spamming all at once.

[Pontus91]

Any news regarding this?

[SukkaW]

I am about to wake my previous PR #40310 up (the PR is currently conflicting with the canary branch, I will start working on it ASAP).

[kvnol]

I disable the prefetch on all links because my server is tired. 😂

[vamcs]

If you're on Next 13 and you have a middleware, this may be the middleware prefetching data (especially if the returned data is an empty object). Check this thread out: #44596

[yannickbuntsma]

I see that in the network tab these requests have status code 304 (Not Modified). Quoting MDN:

The HTTP 304 Not Modified client redirection response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource.

If I'm reading that right and my knowledge is on par, this means that the browser is serving this data from its cache and the server will never receive this request. Based on the HTTP caching rules in-browser, the browser will know when to consider any data in its cache to be stale and refetch the link accordingly.

[daveycodez]

My Vercel logs are saying otherwise