Priority Hints

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Priority Hints
• Specification or proposal URL: https://github.com/WICG/priority-hints, Standardize Priority Hints whatwg/html#3670

Other information

Currently web developers have very little control over the heuristic importance of loaded resources, other than speeding up their discovery using <link rel=preload>. Browsers make many assumptions on the importance of resources based on the resource's type (AKA its request destination), and based on its location in the containing document.

This spec proposes to give developers the control to indicate a resource's relative importance to the browser. This would allow the browser to act on those indications to modify the time it sends out the request and its HTTP/2 dependency/weight so that important resources are fetched and used earlier.

In theory, giving the developer control over priority may lead to an improved the user experience.

[annevk]

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

I'd love to know what @mcmanus thinks about this.

[addyosmani]

We have recently updated the draft spec in https://wicg.github.io/priority-hints/ and an implementation in Chromium (with support for img, link and Fetch). We are hoping this will provide data to help validate the performance opportunities Priority Hints aim to offer.

We would greatly appreciate any signals Mozilla has on the proposal and are happy to discuss any concerns or feedback you might have.

[martinthomson]

It might help if these priorities could be somehow related to those used in other parts of the browser. Establish some expectations around what the browser might do with these hints. Also, whether the intent is to convey an ordering semantic or a weighting one.

The number of priorities seems too high. The number needs justification. See WebRTC for an example of a complex priority model.

[wanderview]

@martinthomson, note that the explainer linked in #25 (comment) is a bit out of date. The link provided in #25 (comment) has only three values; "auto", "low", and "high". Just FYI in case you were looking at the explainer.

Edit: This is the one to look at now, AFAICT: https://wicg.github.io/priority-hints/

[martinthomson]

The smaller number of values is better, but the doc doesn't really say what each means.

[domfarolino]

It might help if these priorities could be somehow related to those used in other parts of the browser. Establish some expectations around what the browser might do with these hints. Also, whether the intent is to convey an ordering semantic or a weighting one.

That's a little fuzzy mostly because it is a "hint", but the main idea is that it is a weighting one, which may affect ordering as well as long as it doesn't mess with normative behavior specified elsewhere (perhaps HTML Standard in some way or another) For example, with multiple images on a page, importance=low/high might affect when the browser actually sends out requests for certain one since the order in which their requests will be fulfilled is not really defined anywhere, so the browser can do what is best for UX in this case (taking the hint into account). On the other hand, importance=low on the pending parser-blocking script script would never allow the main parser to jump over this, scooping up other requests to make before eventually coming back, since that completely defies some of the well-ordered behavior there.

RE relating these priorities to ones used elsewhere in the browser, the idea now is that the importance value would affect the assigned priority relative to other requests of the same type. So if Firefox happens to use a priority of "6" for images, an image with importance=low would ideally be "something less than 6", or "something less than the other images". The goal is to not really define how this compares to how CSS, scripts, or fonts are prioritized, but instead affect the priority relative to requests of the same type. I think we can work on making that clearer, but hopefully that makes sense in the the mean time.

[bzbarsky]

Parsers jump over parser-blocking scripts and do other loads all the time, no? They may not expose those loads to the page itself (but do to the service worker), but they do them.

[domfarolino]

The main parser or something like the preload scanner? It seems by spec the main parser "can't", but I guess either way as long as the effects are not observable to app code and don't break the ordering of things that developers can rely on, as a result of being defined elsewhere that's the best case. Basically, the hint should do what it can to improve UX without breaking other normative behavior if that makes sense. But yes regarding your point, it seems a UA could decide to do something like that.

[bzbarsky]

The main parser or something like the preload scanner?

In Gecko it's the same thing, fwiw. The parser doesn't block on scripts; the tree builder does.

[domenic]

#25 (comment) is pretty good information, and upon a brief skim I didn't see anything quite like it in https://wicg.github.io/priority-hints/. Maybe a section on implementation notes or similar might be a good idea, containing that information in some form.

[domfarolino]

Definitely agreed. That's the plan, thanks for the feedback!

[annevk]

And the scope of these priorities is the document/global, effectively? Or the similar-origin window agent? Something else?

[domfarolino]

I've made a PR to the current Priority Hints spec hopefully clearing up some of the confusion/concerns raised here, and elaborating on #25 (comment). Any feedback would be greatly appreciated / @martinthomson.

@annevk I imagine the document/global but I am also not 100% certain I understand the question. It feels like the importance value would just be more information that would be tacked onto a request and follow it around until it is sent out, so I'm tempted to say the scope would be that of the request's; not sure if that == document/global.

[martinthomson]

@annevk's question here is likely how do you prioritize a request for carousel1.jpg relative to other images, other loads on the same page (do you really want to jump the queue ahead of blocking JS and CSS loads, for example), other loads by the same origin that might be in different browsing contexts, and other browsing contexts? I think that you answered that in #25 (comment) (I'm not sure that I find that answer to be consistent with some of the examples, which seem to show prioritization interactions between different types of resource, but I realize that anything is possible).

Getting priority right is hard, and I'm really nervous about creating extra signaling here. We created this wonderful complex system in HTTP/2 that is looking like a bit of a white elephant in retrospect. This clearly doesn't have the same complexity, but that doesn't mean it is any less of a problem if it turns out that we don't - or can't - use it.

A lot of this is predicated on not having good priority heuristics in browsers and poor information about priority in servers. For instance, the fact that a carousel image is currently display:none might not be available to a browser when it makes the request for that image. Maybe the CSS or script that sets that attribute isn't in just yet. But you could statically set display:none in the HTML and rely on the browser making the right choices. Using script to generate the necessary DOM for low priority resources would seem to achieve much of the same outcome.

Also - for HTTP/2 and later - we wouldn't mind that the request goes out so much. Requests are small. More so if the server knew not to send the image bytes straight way, unless that blocks other more important requests from going out, which is unlikely.

The priority API for fetch is much harder to justify. Is this intended to be just one way of controlling relative priority at this layer, or as a means of driving the priority signaling in HTTP/2 and HTTP/QUIC? Could this addition interfere with a more comprehensive prioritization API?

It seems like there is value in tuning rel=preload, but then I'm not sufficiently versed in that (I didn't know that it blocked loading for other resources, for instance. Is that really universally true?).

[yoavweiss]

A lot of this is predicated on not having good priority heuristics in browsers and poor information about priority in servers.

Yes, this is predicated on developers having the best knowledge about their apps and the priorities of their different components, and giving them a way to communicate that knowledge to the browser.

Ideally, we want the make it extremely easy for developers to indicate clear signals of their resource priorities, as current heuristics are using proxy attributes at best (e.g. "the script is non blocking, so it must be low priority", which is not always true and creates the wrong incentives).

For instance, the fact that a carousel image is currently display:none might not be available to a browser when it makes the request for that image. Maybe the CSS or script that sets that attribute isn't in just yet. But you could statically set display:none in the HTML and rely on the browser making the right choices. Using script to generate the necessary DOM for low priority resources would seem to achieve much of the same outcome.

Yes, we can avoid creating the DOM nodes of low priority resources until they are needed and only then generate them dynamically. However, the performance problems that the web is facing are not due to fact that developers are not using enough JS 😜 . We want to enable developers to indicate priority without taking full ownership of the entire DOM generation process. Pushing more work to the point in which the resource is needed will also introduce processing latency, which will likely delay those requests, resulting in suboptimal performance.

Also - for HTTP/2 and later - we wouldn't mind that the request goes out so much. Requests are small. More so if the server knew not to send the image bytes straight way, unless that blocks other more important requests from going out, which is unlikely.

Theoretically, that is true. In practice, there is no single server. The typical website is often comprised of dozen or more servers, lacking any coordination when it comes to resource priorities. Only the client can be aware of the multiple servers it has to manage in order to load the page.

That wouldn't matter much if we were to aim Priority Hints only as a mechanism to manipulate H2 priorities, as each server regards them in isolation. Therefore, I believe H2 priorities are not sufficient, and in the long run, we would need to use request priorities + priority hints in order to either delay low priority requests from contending with higher priority ones, or have the browser perform network level flow-control-based coordination between the different servers.

Either way, the browser will need better priority info in order to get the above right.

The priority API for fetch is much harder to justify. Is this intended to be just one way of controlling relative priority at this layer, or as a means of driving the priority signaling in HTTP/2 and HTTP/QUIC? Could this addition interfere with a more comprehensive prioritization API?

It is intended as a relative priority for that layer (e.g. distinguish fetch() of critical data from non-critical one).

I'd imagine that if we were to define a comprehensive and explicit prioritization API, it will override those hints. Are there plans for such an API?

It seems like there is value in tuning rel=preload, but then I'm not sufficiently versed in that (I didn't know that it blocked loading for other resources, for instance. Is that really universally true?).

Preload does not block, but since its requests currently get the default priority for the destination without much more heuristics, they may get higher priority than the developer intended, or get added to the queue earlier than the developer intended, resulting in preloads "jumping the queue" and get downloaded before more critical but naturally discovered resources.

[martinthomson]

This seems to be in tension with ongoing work in HTTP around defining a priority signaling scheme. I think we should defer until those two items are resolved.

[martinthomson]

OK, I just found this christmas present, so I think that we can close this one without filing a position.

[domfarolino]

We'll definitely be circling back once we explore our implementation, but this should not be a priority for Firefox right now, yeah