TAG review request: https://github.com/w3ctag/design-reviews/issues/241
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.
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.
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
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.
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)?
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:
Requesting approval to ship?
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.
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.
Was there any discussion on including <video>, <audio> in this initial proposal? Speaking for the media team, it's definitely interesting to us.
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.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMWgRNY5dHo6nkqT6z11UTaJ31i_K9DptLZ2WTBmQ99zOkjWwA%40mail.gmail.com.
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>?