whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.16k stars 2.69k forks source link

Should we allow delaying video preload until it becomes visible? #2364

Open xxyzzzq opened 7 years ago

xxyzzzq commented 7 years ago

Currently we allow delaying video autoplay until it becomes visible. However they will still load when they are offscreen.

Should we also delay the preload behavior? @dalecurtis @foolip @mounirlamouri

Yay295 commented 7 years ago

That seems a bit contradictory to the whole idea of preloading.

foolip commented 7 years ago

Strictly speaking this is already allowed, because the preload attribute and no behavior is required. I don't think this is great, though, it means that almost no shared tests at all can be written for the attribute.

For a long time the behavior of Chrome for Android was to load nothing until the video began playing, so it's probably web compatible to not load anything until on-screen.

In an ideal balance between responsiveness and data savings, media would begin preloading just before a video becomes visible, so that it can be playing immediately. It's probably not write a heuristic that does this well, but with enough control sites might be able to do a good job themselves. Would that be worthwhile?

mounirlamouri commented 7 years ago

I agree that changing preload to depend on visibility might not be a good idea because it could cause more harm than good. We are risking websites moving away from preload and doing their own loading where we would have no control as browsers. Instead, browsers can have special preload behaviours in some situations. For example, Chrome Android still do not preload media files for some low end devices or when Data Saver is on.

dalecurtis commented 7 years ago

Well, sites controlling loading behavior is exactly what MSE is for; and which the preload attribute has no effect on. Last I looked at the data presence of a preload attribute if fairly rare over all pageloads, so perhaps what we really want is just better behavior when no preload attribute is specified.

Whoops, forgot to say I like the "load as almost visible" approach, but it does seem like it might be hard to implement. Requiring a distance test versus an intersection test, for which I'm not sure of the implementation complexity.

mounirlamouri commented 7 years ago

It's hard to estimate the preload usage as we don't have direct record of how much the attribute is used but only of the effective preload value. Though, for the record, only 4% of page loads have an HTMLMediaElement so all data about preload have to be looked within that context.

@dalecurtis wouldn't requiring preloading to be visible actually make preload entirely moot? Let say I have a video in an article set as <video autoplay muted>, does that mean it will start loading when visible then play later, potentially breaking the experience I was building for my users? (ie. get the animation to play while reading the article). Asking websites to switch to MSE for things like that sounds a bit too much IMO.

dalecurtis commented 7 years ago

I think it's debatable how useful preload actually is; but after some more thought I do think this would probably be confusing to authors and I think we may have other implementation specific knobs we can tune to reduce load complexity.

This is getting a bit off topic for a spec bug, but perhaps it's enough to switch to preload=metadata by default and additionally in the non-visible w/ poster image case, we don't spool the decoders until visible/playback begins. This may have spec implications because currently playing status is hidden from the underlying player until HAVE_FUTURE_DATA (which we wouldn't reach if we just preload metadata), but possibly this is just a Chrome implementation issue.

foolip commented 7 years ago

As long as readyState HAVE_CURRENT_DATA is reached and the width/height of the video is known, I think that would be in conformance with what the spec requires. Are there formats where decoding the first frame is the only way to learn the size of the video?

It would be not great if it's possible to see differences in readyState (or networkState, or buffered ranges) based on the video intersecting the viewport. If that's the best implementation strategy, then even if already permitted, it might be good to call out the points in the spec where such decisions can optionally be made, if others want to use the same heuristics. (Once it's been implemented for long enough, something will depends on the details.)

patrick-mcdougle commented 9 months ago

What about adding a value to the autoplay attribute? autoplay="inView" which would follow the preload guidance as already specified, but would not play until it entered the viewport.