Intent to Implement: Priority Hints API

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.