[whatwg/fetch] Standardize Priority Hints (#1319)

Priority Hints is an API that lets developers signal to the browser the relative importance of resources, so that the browser might take this into consideration when prioritizing the request. The WICG repository for Priority Hints is [here](https://github.com/WICG/priority-hints) and the explainer spec is [here](https://wicg.github.io/priority-hints/). The explainer spec lays out some good use cases. Prioritization might take the form of modifying a request's HTTP/2 or HTTP/3 priority, delaying when a request is sent out, etc.

Browsers already have an internal implicit mapping for fetch prioritization, usually based on content type and combined with other factors (background tab, preload, prefetch, in-viewport, parser-blocking, sync XHR, etc). The prioritization usually impacts the order in which requests are made and, if the underlying protocol supports multiplexing and prioritization, the protocol-specific prioritization of each stream.

Priority Hints gives a developer a mechanism to indicate to the underlying browser, a hint about the relative priority of a given request, either indirectly through the ```importance``` attribute on an HTML element that requires a resource load (img, script, preload, etc) or explicitly as an attribute on a fetch API call. The browser can take the importance hint into account when evaluating priorities to assign to individual resources.

The intent is to provide an additional developer-controlled signal to help with cases where heuristics are not enough to result in optimal loading. There should be no functional changes as the underlying processing model is not altered.

The working group settled on ```high/low``` signals (in addition to the default of ```auto```) as a way to give developers some input into the prioritization without exposing the complexity of the different underlying protocol implementations and to continue to allow for browser heuristics. Chrome has documented the current prioritization heuristics [here](https://docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwNFiEP4TZS-YLRp_RuMlc/edit?usp=sharing) including the changes that Priority Hints apply.

## Concrete Use Cases

### Boosting Image Priority
By default, Chrome gives images a relatively low priority because they do not block the parser or the DOM Content Loaded event from firing. There are some heuristics to boost the priority of in-viewport to get the visual content loaded sooner but that priority boost can only be applied after the initial layout has been performed and the images within the viewport can be identified.

Priority hints on either the image tag or on a preload for a given image would enable developers to signal the most important images for the user experience and cause them to potentially load sooner than they would otherwise. In Chrome, this could be done at the earliest stages of the HTML parsing and not rely on being able to re-prioritize requests that are already in-flight.

### Signalling Relative API Priority
On fetch, specifically, all API calls for the same content type are treated equally. We have cases where we need to be able to make high-priority API calls in response to user input (type-down autocomplete for example) while there are also low-priority background API calls in-flight.

Priority Hints would allow developers to improve the multiplexing of the raw API calls and potentially get more responsive interactions in that situation.

### Boosting the Priority of Async Scripts
By default, Chrome gives async scripts a relatively low priority because they do not block the parser. There are cases where those same async scripts are critical to rendering the user experience (common with loaders for app frameworks). There is a hack that developers currently use which is to add a preload for the same script which causes Chrome to boost the priority but it is a Chrome-specific hack that leverages side-effects of preload rather than an explicit signal.

Priority Hints would allow for a clean, explicit signal from a developer that a given script is important, even though it is not parser-blocking.

## Spec Changes

For fetch, I would proposed adding a ```importance``` to [request](https://fetch.spec.whatwg.org/#concept-request) that is ```high```, ```low``` or ```auto``` which is ```auto``` unless stated otherwise.  I'm happy to supply a PR but wanted to discuss here first.

There will be associated changes to the HTML spec as well to add importance attributes to the relevant elements.

## Current Status in Chrome

Chrome is running an origin trial in Chrome 96+ (currently in Canary) with support for Priority Hints through HTML attributes and as an ```importance``` attribute on Request for fetch API calls to test the use cases listed above as well as the developer ergonomics around using the API.

There was an earlier origin trial in 2018 that was largely targeted at the use case of boosting async script priorities but the majority of partners in the trial had already implemented the script preload hack so there wasn't a lot of traction on it at the time. Since then, there have been other cases that have come up that don't already have existing hacks so hopefully we can get a cleaner read on it.

The last attempt also envisioned cascading the importance beyond the initial resource fetch to later work done by that resource (iframes, scripts, etc). That was beyond the scope of the working group's efforts and is no longer being explored. Priority Hints as implemented in the origin trial and as planned are expected to impact the fetching of the initial resource and nothing else (including execution).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1319