Intent to Implement: Priority Hints API

[Dominic Farolino]

Contact emails:

ad...@chromium.org, domfa...@gmail.com, kenji...@chromium.org, yo...@yoav.ws

Explainer

https://github.com/WICG/priority-hints/blob/master/EXPLAINER.md

Design Doc/Spec:

https://wicg.github.io/priority-hints/

http://docs.google.com/document/d/1JutABSrbPEWMLW0ZXtySdd-4OOisf4Rbc00T_hHFc3U/

TAG review request: https://github.com/w3ctag/design-reviews/issues/241

Summary:

The Priority Hints API lets developers signal to the browser how much a resource-fetching HTML element matters to the user experience. The browser may take this signal into consideration when prioritizing the request.

Motivation:

The WICG spec explains this well, but mostly this revolves around when developers wish the browser to prioritize certain elements in a way other than their likely defaults. There are situations where a developer might know the priority of a resource and its importance to a page better than the browser. This API gives the developers a way to communicate this to the UA. Helpful use cases can be found in the WICG spec.

Risks

Interoperability and Compatibility

For compatibility, the risk is close to zero, as this is a brand new attribute and there's no room to believe that there's existing content with this attribute which may change behavior once this ships.

For interoperability, there may be some risk if other browsers fail to adopt this feature (as we have no current signals from them). Since the feature is a hint, it will not cause any content to break (although other browsers may be slower to load such content as a result). The hint nature of the feature also means that it would be easy to unship it without content breakage (but with potential slow-down in browsers that implement), if it turns out to be a bad idea.

Firefox: No public signals

Edge: No public signals

Safari: No public signals

Web developers: feedback from potential partners suggest a strong interest in the API

Activation

Developers can use this feature immediately; it is completely opt-in, and there is not much need for a polyfill. As discussed on the WICG GitHub, certain frameworks have simulated some of this behavior with a scheduler, but most of the benefit here comes from native resource priority scheduling.

Debuggability

Currently, the DevTools networking tab can display a “Priority” tab, which displays the DevTools priority associated with the computed Blink priority of a resource request. We’ve discussed that DevTools should indicate, in this tab, whether an “importance” value (currently as an element attribute or RequestInit member) had any effect on the actual resolved priority. Please see the design document for specific thoughts. This is likely out of scope for an initial implementation.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

Not required for I2I, but we think we can test for IDL support of the attribute in a way similar to that of decoding on supported elements, as well as support in the RequestInit dictionary for the fetch() API. Given the hint-nature of the feature, and its intentionally weak spec language, it doesn’t seem that we can test much regarding resource prioritization initially.

Link to entry on the feature dashboard:

https://www.chromestatus.com/feature/5273474901737472

Requesting approval to ship?

No.

[Addy Osmani]

Thanks for getting out the I2I, Dominic! 

Although Priority Hints are still early on, one of our hopes with exposing an implementation is to get developer feedback on core pieces of the design:

• Are the number of states for hinting "importance" sufficient? (low, high, auto). At TPAC, we had vendor feedback that a smaller, simpler number set of values were preferable and easier to explain to developers.
• Are developers able to reason with how this fits in with a world of other Resource Hints and preload? If not, we can provide better explanations for this in the spec draft.
• Are our current thoughts for handling subresource request prioritization reasonable? (e.g subresources get the same priority as their parent)

[Ilya Grigorik]

Yay! Excited to see this in the works. A much needed primitive.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0d89f9c0-cd3a-4641-97ac-92759267947e%40chromium.org.

[Dale Curtis]

Was there any discussion on including <video>, <audio> in this initial proposal? Speaking for the media team, it's definitely interesting to us.

- dale

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

[Kinuko Yasuda]

Thanks Dominic for driving this!

On Tue, Apr 17, 2018 at 3:45 AM Dale Curtis <dalec...@chromium.org> wrote:

Was there any discussion on including <video>, <audio> in this initial proposal? Speaking for the media team, it's definitely interesting to us.

​(As one of them who made suggestions on starting with a smaller set of resource types) I think we'll be definitely interested in supporting more types ​once we have a clearer feedback/consensus on how this feature should look.  Out of curiosity, will there be concrete motivating use cases for having this for <video> <audio>?

 

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

[Harald Alvestrand]

If playback of video sources is resource constrained (on cpu, for instance), prioritization definitely makes sense.

In most cases, audio isn't a huge resource issue, but definitely needs to be prioritized ahead of video; choppy video is irritating, while choppy audio can be a deal-breaker.

For WebRTC network-transmitted media, there's a separate priority API  defined (but not implemented in Chrome at the moment), using 4 values: http://w3c.github.io/webrtc-pc/#priority-and-qos-model

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNY5dHo6nkqT6z11UTaJ31i_K9DptLZ2WTBmQ99zOkjWwA%40mail.gmail.com.

[Kinuko Yasuda]

Thanks Harald!  Currently Blink always load the media resources at low priority regardless of whether it's audio or video, letting developers raise priority of some of the elements or depending on visibility etc could make sense (i.e. once we get data for smaller set of basic ones we can certainly consider widening the coverage as we go on).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dale Curtis]

On Sun, Apr 22, 2018 at 11:45 PM Kinuko Yasuda <kin...@chromium.org> wrote:

Thanks Dominic for driving this!

On Tue, Apr 17, 2018 at 3:45 AM Dale Curtis <dalec...@chromium.org> wrote:

Was there any discussion on including <video>, <audio> in this initial proposal? Speaking for the media team, it's definitely interesting to us.

​(As one of them who made suggestions on starting with a smaller set of resource types) I think we'll be definitely interested in supporting more types ​once we have a clearer feedback/consensus on how this feature should look.  Out of curiosity, will there be concrete motivating use cases for having this for <video> <audio>?

Since this would only affect src= tags; sites like YouTube, Vimeo, Netflix, etc which use Media Source Extensions for loading and tend to have primary + secondary media content won't benefit. The remainder is likely sites with sounds, background, or inline src= videos that are not as important the main content. That said there are still quite a few sites not using MSE while having primary + secondary video content; e.g., imgur and gfycat would likely benefit from being able to prioritize the main content over secondary content. In general as time goes on the line between images and video is likely to blur, so thinking about a video in the same places as an image is used today is illuminating when considering use cases.

- dale

[Dominic Farolino]

Thanks a lot for the messages here, and Kinuko for responding as I've been pretty busy with end-of-semester projects and things of that sort. The use cases definitely make sense and I appreciate the bit about the lines between videos/images blurring in the future, though right now I tend to agree with Kinuko in that we'd like to gather some data on a smaller set of elements, expanding coverage as we go a bit later. Right now the intended list of elements for initial experiments I believe are:

• <link> (including rel=anything but import)
• <script> (<script type=module> eventually)
• <img>
• <iframe>
• Possibly Link: header