Standardize Priority Hints

[pmeenan]

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 and the explainer spec is here. 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 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 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.

The issue tracking the HTML spec discussion is here.

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).

[pmeenan]

Chrome has shipped this in 103.

@valenting can you comment on Mozilla's interest as a second implementor?

[valenting]

I think the spec in its current state is quite reasonable.
The Gecko networking team intends to implement this in early 2023.

[pmeenan]

FYI, for anyone following along here that might have opinions, there's some discussion going on in this thread in the priority-hints repo about maybe not exposing priority at this time on the request object (for reading when intercepting, I still feel pretty strongly that it needs to be available for setting on RequestInit).