Intent to Temporarily Remove: link rel=preload types 'audio' and 'video'

[bra...@microsoft.com]

Primary eng emails

br...@microsoft.com

Summary

Temporarily remove the 'audio' and 'video' link rel=preload 'as' types.

Motivation

Issues raised and discussed in https://crbug.com/735014 and https://crbug.com/896279 have shown that in practice requests that make use of range or other custom headers do not typically attach to the same resource contained within the preload cache. This affects both audio and video elements along with their corresponding preload types.

Explain why this feature should be removed.

The current behaviour is misleading for developers given that indications are the resource is preloaded and yet the audio/video element typically will re-fetch the resource. This can cause unintended behaviour and potentially even double downloads. These types of requests and their interaction with the preload cache need to be spec'd properly in terms of the Fetch. The issues are tracked as follows:

https://github.com/w3c/preload/issues/97

https://github.com/whatwg/fetch/issues/590

In order to mitigate the current cache behaviour and send a clear signal to developers about how their page will behave we can remove the audio and video "as" declarations from the link rel=preload implementation until the Fetch spec issue is resolved and implemented.

Interoperability and Compatibility Risk

There is interop concern in that other implementors do support the audio/video types for the as attribute of link rel=preload. However since the current implementation causes these preloaded resources to not be reliably consumed and may only result in an extra download there looks to be a bigger compat issue exposing these types. Given this feature is a perf/optimization one it shouldn't result in site breakage as the audio/video elements would play regardless of the preload happening or not.

Alternative implementation suggestion for web developers

While these types are removed the preload attributes on the audio/video media elements may be suitable to workaround this.

Entry on the feature dashboard

This is a small temporary change that fits under the existing preload feature. It is a subset of the possible types.

[Yoav Weiss]

Thanks for tackling this!

The current situation is one where preloaded videos may get double downloaded, so temporarily removing support is the right thing to do.

LGTM1

On Wed, Jan 30, 2019 at 6:13 PM brandm via blink-dev <blin...@chromium.org> wrote:

Primary eng emails

br...@microsoft.com

Summary

Temporarily remove the 'audio' and 'video' link rel=preload 'as' types.

Motivation

Issues raised and discussed in https://crbug.com/735014 and https://crbug.com/896279 have shown that in practice requests that make use of range or other custom headers do not typically attach to the same resource contained within the preload cache. This affects both audio and video elements along with their corresponding preload types.

Explain why this feature should be removed.

The current behaviour is misleading for developers given that indications are the resource is preloaded and yet the audio/video element typically will re-fetch the resource. This can cause unintended behaviour and potentially even double downloads. These types of requests and their interaction with the preload cache need to be spec'd properly in terms of the Fetch. The issues are tracked as follows:

https://github.com/w3c/preload/issues/97

https://github.com/whatwg/fetch/issues/590

In order to mitigate the current cache behaviour and send a clear signal to developers about how their page will behave we can remove the audio and video "as" declarations from the link rel=preload implementation until the Fetch spec issue is resolved and implemented.

Interoperability and Compatibility Risk

There is interop concern in that other implementors do support the audio/video types for the as attribute of link rel=preload. However since the current implementation causes these preloaded resources to not be reliably consumed and may only result in an extra download there looks to be a bigger compat issue exposing these types. Given this feature is a perf/optimization one it shouldn't result in site breakage as the audio/video elements would play regardless of the preload happening or not.

AFAIK, WebKit have also unshipped preload for video and audio request destination, for somewhat similar reasons.

I also believe Firefox never shipped their implementation.

So the main compat risk would be from developers who explicitly look for video and audio support (through the `as` attribute IDL reflection) and break if it's not supported. I doubt that is common, as that would be extra work, and break their sites in Safari today for no good reason.

 

Alternative implementation suggestion for web developers

While these types are removed the preload attributes on the audio/video media elements may be suitable to workaround this.

Entry on the feature dashboard

This is a small temporary change that fits under the existing preload feature. It is a subset of the possible types.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9522e93-b4de-4c9f-84d9-e937fa9a0ce3%40chromium.org.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgzuKdwhPhVOtf%2BU785az_SL9Rg-zyvG_LMpw1_MyYkVg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Mike West]

LGTM3.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zwg5zqhtrbppqq%40cicero2.linkoping.osa.