Gatsby Link: high-priority prefetch requests on focus?

[robinmetral]

Summary

Gatsby Link is making low-priority prefetch requests for links in the viewport, and high-priority requests onMouseOver.

Could this be matched for keyboard navigation by making high-priority requests onFocus?

Basic example

n/a

Motivation

This would make navigation faster for keyboard users.

[herecydev]

Seems sensible, I think it would have to listen to both onMouseOver and onFocus

[robinmetral]

Yep, it looks like a small change if we want to tackle this.

Here:

gatsby/packages/gatsby-link/src/index.js

Lines 185 to 190 in dacbbae

	onMouseEnter={e => {
	if (onMouseEnter) {
	onMouseEnter(e)
	}
	___loader.hovering(parsePath(prefixedTo).pathname)
	}}

I guess we'll just want the same for onFocus.

              onMouseEnter={e => {
                if (onMouseEnter) {
                  onMouseEnter(e)
                }
                ___loader.hovering(parsePath(prefixedTo).pathname)
              }}
+             onFocus={e => {
+               if (onFocus) {
+                 onFocus(e)
+               }
+               ___loader.hovering(parsePath(prefixedTo).pathname)
+             }}

Let's wait for more feedback from others and I'll make a PR if we want to proceed with this 🙁

[marcysutton]

That sounds pretty cool. One thing that comes to mind is that for users who rely solely on the keyboard, they could potentially be fetching more data than they really need because they're moving focus through all the links. It isn't as 1:1 of an experience to mouse users, who have more of a choice to hover on a link or not. I'd be curious to hear what the @gatsbyjs/core team has to say.

[wardpeet]

@marcysutton I had the same issue like you mentioned. What's the use case @robinmetral,? Maybe we can add some extra properties so you can extend the Link component and wrap this functionality yourself.

[robinmetral]

Well, the use case is the same as for the current prefetching feature of Gatsby Link: faster navigation and therefore (arguably) a better UX. The existing low-priority requests are also probably downloading a lot of "unnecessary" data. There is no big need of course, I mostly noticed this while navigating my site - doing it with keyboard only makes routing much slower.

We could also argue that, assuming that keyboard users are on desktops, not mobile (can we assume this?), networking is generally faster and the extra requests would not cause any issues while improving keyboard navigation.

I think that exposing the prefetching mechanism to users could also work without needing to build this into the component, as you mentioned @wardpeet.

[wardpeet]

They can be on desktop but might be wired to a hotspot. I rather have this as a new property so people can add their logic and use React's composition strategy instead. A feature like this would add some complexity like, should we preload right away, or should we wait a few milliseconds or seconds?
I mostly want to see perf numbers before we take something on like this. What's the real benefit on desktop if we would enable this by default.

The existing low-priority requests are also probably downloading a lot of "unnecessary" data.

We're going to change that to be less aggressive.

[robinmetral]

Completely agree. I'd be more than happy to have this as an option 🙂 Let me know if there's anything I can help with.

[marcysutton]

I should also chime in that mobile users employ Bluetooth keyboards quite often, so I don't think mobile usage can necessarily predict whether someone will or won't use a keyboard.

[erpatterson11]

I think that exposing the prefetching mechanism to users could also work without needing to build this into the component, as you mentioned @wardpeet.

I second this suggestion. It would be helpful to expose the prefetch functionality outside of the Link component so that devs can choose when to prefetch routes. I've had several sitatuions where I wanted to pre-fetch a route on specific user interactions (like focusing on a search bar) but I didn't want to use the default Link behavior.

This is something that Next.js has implemented that I wish I had in Gatsby.

[wardpeet]

Noted that's actually a good idea 👍

[mantagen]

+1 for exposing prefetch/loadPage.

On this site I've made, I'm noticing that on mobile, opening the menu is running loader.prefetch for the links but not running loader.loadPage (which happens on hover). It means that UX is notably worse on touch-only devices.

I think clearly there are cases when you would not watch to load the page of each visible links, but for a lot of small/medium sites, I think the trade off is worth it. Allowing the developer to make that choice feels like a no-brainer.