Improve prefetching w/ ViewTransitions #661
Replies: 4 comments 8 replies
-
|
Thanks! I think I understand most of this. I don't quite understand the delay though. As you said, on mobile that's likely going to be navigation, so delaying 65ms just slows down the navigation. But re-using a link node to change the |
Beta Was this translation helpful? Give feedback.
-
|
I'm happy to elaborate on the delay: Whenever a user starts a scroll motion on a smartphone, the So some kind of delay ensures it is more likely that an initiated prefetch is actually useful and not only wasted network transfer/CPU time. Instant.page goes a little bit beyond the |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for elaborating @kurtextrem. In that case I think both of these additions are worth pursuing to some extent. Still curious about the exact conditions here. Should these delays be focused on mobile? On the slower networks only? |
Beta Was this translation helpful? Give feedback.
-
|
The 65ms delay is appropriate for desktop only. On mobile, users touch a link (click timestamp minus touchstart timestamp) only 90 ms on average, so there’s unfortunately no time for using a delay as another heuristic. Regarding the 1111ms last touch check in mouseover, going by memory from a few years ago (!) it’s there because tapping a link ends up triggering regular mouse events afterwards. I observed that on Android (I guess I tested in multiple browsers) it took one second of holding your finger on a link for a contextual menu (with options like “Open in new tab” etc.) to appear, at which point it should mean that the mouseover wasn’t triggered by a touch event (which would have already triggered a prefetch), but is indeed the user hovering their mouse (or equivalent device). I added 100 ms (well, 111) as a safety precaution in case Android/browsers would mess that timing if they were to freeze at that time. (I’d like to eventually revisit the issue and add a comment to that magic number in instant.page’s source.) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the explanation! Maybe it's also worth exploring |
Beta Was this translation helpful? Give feedback.
-
|
I doubt it. Mouse and touch ideally use different prefetching strategies, and in instant.page they’re configurable. The only advantage left, pens, are too much of a minority to worry about for my part. (I don’t handle keyboard navigation either.) |
Beta Was this translation helpful? Give feedback.
-
|
As often, it's a matter of finding a setting that usually works well, even if we can only speculate about the nature of the applications. |
Beta Was this translation helpful? Give feedback.
-
I certainly agree on that part. To give a comparison, Next.js will prefetch any link that is scrolled into viewport (or is in viewport) if In any case, we should definitely keep the customization option + enrich docs with examples. From my own experience 65 ms does not lead to too many wasted prefetches (and if so, it mostly impacts desktop). |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I like the idea of I plan on writing a proposal soon that's a sort of "view transition additions" proposal that includes a bunch of smaller things like new events, a JS API for triggering navigation, and likely this could be wrapped up in this as well. |
Beta Was this translation helpful? Give feedback.
-
|
I should probably write a little more clearly: What worries me is the lack of separation of concerns: there is an official prefetch integration (@astrojs/prefetch) and an opinionated strategy within ViewTransitions. Wouldn't it make more sense to inform the user about the need for a prefetch strategy and to keep additional prefetching out of the ViewTransition router? |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure if that isn't mixing two things. In ViewTransitions we're proposing a delay for prefetching on strong user signal (hover), in @astrojs/prefetch it looks like to me it's an alternative to Quicklink/Next.js (prefetch what's in viewport). The latter has a much higher chance for prefetching waste (as not every link in viewport will be clicked, only one of N) We could of course also say we want to change @astrojs/prefetch... but that might explode the scope a bit? (e.g. for @astrojs/prefetch we could even introduce |
Beta Was this translation helpful? Give feedback.
-
|
I think prefetching is important to ensure snappiness. In Next.js when you use the In the meantime I think we can give better defaults and more control. @kurtextrem's idea above of |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Body
Summary
Currently, the view transition "router" does not cancel previous prefetches and triggers new prefetches on hover, touchstart and focus immediately.
If you think about an eCommerce shop where you have a grid of products on any product listing page, this will lead to many many prefetches getting triggered at once.
Background & Motivation
Instant.page which innovated the approach of prefetching on hover has a default delay of 65 ms and is customizable for this reason.
Additionally, a previous prefetch is not cancelled when a new one is initiated, which could lead to congestion of the network (think 15 prefetches at once, as there is no limit of active
<link rel="prefetch"in Chrome), this is more an issue on mobile networks (e.g. flaky internet etc. leading to request stalling or similar).Goals
importanceattribute), while we do so, we could also increase the priority of the fetch itselfExample / Implementation
Fetch delay
<ViewTransitions fetchDelayMs={65}>fetchDelayMs, set to 65 by defaultCancel previous prefetch
Instead of checking if a node with the to-be-prefetched URL exists, we use one prefetcher node and clear the attributes before triggering a new prefetch on mobile.
In addition, currently, no prefetch is made when we're on 3G or 2G, however, I'd say we can make a prefetch on 3G and 2G if we cancel the previous one (same for
saveData). A prefetch on 2G/3G definitely makes sense, because whenever a user touches a link (touchstart), on a mobile it's likely it becomes a click afterwards (as there is no real hover mechanism on mobile). So any head start here has immediate effect on loading performance on slow networks.Prefetch & Fetch priority
As the
fetchis triggered only when we're transitioning to the next page, it makes sense to run it with high priority:On desktop, as users could hover over multiple elements, it does not make sense to add
importanceto thelinktag. However, on mobile, as mentioned before, a touch likely means we'll trigger a navigation, thus it makes sense to add importance=high there.https://github.com/withastro/astro/blob/main/packages/astro/components/ViewTransitions.astro#L261
link.setAttribute('importance', 'high');Beta Was this translation helpful? Give feedback.
All reactions