feat: More advanced YouTube pre-load decisions based on device #309
Conversation
|
Size Change: +27 B (0%) Total Size: 51.4 kB
ℹ️ View Unchanged
|
oliverlloyd
requested review from
SiAdcock,
arelra,
mxdvl,
jamie-lynch and
OllysCoding
There was a problem hiding this comment.
This is exciting. I wonder, though, adding all these heuristics for mobile is really what we want to do. There’s also some conflation of touch-only, touch-capable and mobile devices.
Could simply waiting for touchstart and triggering hasUserHovered be enough?
src/YoutubeAtom.tsx
Outdated
| const loadIframe = | ||
| iframeSrc && (!hasOverlay || hasUserHovered || hasUserLaunchedPlay); | ||
| let loadIframe: boolean; | ||
| const isMobile = /Mobi/.test(navigator.userAgent); |
There was a problem hiding this comment.
I think this is more about testing touch v pointer than it is about mobile devices. Maybe the variable name should reflect that.
I know I was the one originally mentioning touch devices, but thinking about this again, I’m wondering if the best isn’t to just listen to a touchstart event that would act as a hover state.
It’s important to note that these types of optimisations based on the availability of touch have a fundamental flaw: they make assumptions about user behavior based on device capabilities. More explicitly, the example above assumes that because a device is capable of touch input, a user will in fact use touch as the only way to interact with it.
There was a problem hiding this comment.
That's a really interesting, and probably very valid, point. I'm going to look into this some more (thanks for the links!) and chat it through with team 👍
There was a problem hiding this comment.
I discussed this with @OllysCoding and we both agreed your points are spot on @mxdvl and so I've refactored this PR to use onTouchStart in addition to onHover. The result of this is a my previously rather large PR is now basically a one-liner.
It's true that this means we sometimes delay the point at which a video is downloaded but as per your points and the linked articles I don't think we were accurately making the decisions about when to do this before and waiting until the user actually interacts is more accurate.
What does this change?
This enhances the logic we have for deciding when to pre load the iframe by taking into account if the user is on a mobile device or not and also listening for the
onTouchStarteventWhat is pre loading?
A previous PR added the logic to defer the loading of the YouTube iframe. By doing this we reduce the amount of content that gets initially downloaded on page load, improving the reader experience