Inspiration from/comparison to Priority Hints

[rmarx]

Priority Hints (https://wicg.github.io/priority-hints/) are a proposal to allow developers to indicate relative importance of resources in order to promote or demote their relative priorities directly in the HTML.

For example:
<img src="img/carousel-1.jpg" importance="high">

The way this is currently implemented in Chromium:
https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/loader/fetch/resource_fetcher.cc?sq=package:chromium&g=0&l=195

This seems relatively straightforward, though according to @yoavweiss, they might make it more fine-grained (e.g., also add queueing/delaying of requests).

I am creating an issue for this mainly because I see a bit of overlap in the concepts of Priority Hints and this draft (though the "hints" move in different directions). Maybe it's interesting to think about a single, unified mechanism (or maybe not).

[kazuho]

Thank you for starting the discussion. I agree that by working together we could provide website owners more flexibility to control prioritization.

Am I correct in assuming that Chrome maps importance=high to the urgency of script and CSS files that block rendering, and that importance=low is mapped to the urgency of image files?

Assuming that is the case, the most straightforward way would be to map them to urgency=blocking and urgency=non-blocking. For example, <img src="img/carousel-1.jpg" importance="high"> would generate a GET request with Priority: urgency=blocking, progressive=?1, instead of the default (which would be Priority: urgency=non-blocking, progressive=?1).

If we are to go further than that, Priority Hints might allow arbitrary text to be set in the "importance" element, that when neither "high" or "low", gets appended to the value of the Priority header. For example, <img src="img/i-use-my-own-prioritization.jpg" importance="precedence=61"> would generate a GET request of Priority: urgency=non-blocking, progressive=?1, precedence=61 (in this case, the default values of urgency and progressive are being used). The website-specific prioritization instruction "precedence=61" could mean that the image is the 61th most important asset of the web page.

WDYT?

[LPardue]

A simple (rhetorical) clarification question: are priorirty hints expected to be seen "on the wire".

From https://wicg.github.io/priority-hints/#examples-0

The importance hint may be specified in the document markup, MAY be provided via JavaScript, MAY be provided via the HTTP header, and MAY be dynamically added to the document.
Link: </app/style.css>; importance=high

So this is a origin -> client header flow. But representation of this information in headers, in the other direction, are not supported (yet)?

[kazuho]

So this is a origin -> client header flow. But representation of this information in headers, in the other direction, are not supported (yet)?

That is my understanding. Priority Hints are just hints that (might) affect how the browser builds the H2 prioritization tree.

[rmarx]

afaict, yes, these are hints from the origin to the client. However, like I said in the original post, I feel that maybe there are opportunities that these can be combined somehow, though that would have to be more fine-grained than just the high/low they have now.

However, that's something they have been very hesitant about in the design. They explicitly did not want people setting too fine-grained settings (e.g., set the H2 weight directly). While I do personally like Kazuho's proposal of something like importance="precedence=61" (or just more generally, including that value directly in the HTTP header), that doesn't seem like something they would want to support, though I can be wrong. Maybe @yoavweiss might have some thoughts on that.

I'm also not sure the mapping you propose is something we would want Kazuho: importance="high" suddenly making an image blocking feels to coarse (don't think that's what currently happening in the Chrome implementation). This seems like a perfect candidate for what I proposed on the mailing list though, having some kind of a more general weight/priority-level next to urgency + progressive (e.g., normal image is level 1, importance="high" image is level 5 etc.)

[kazuho]

@rmarx

afaict, yes, these are hints from the origin to the client. However, like I said in the original post, I feel that maybe there are opportunities that these can be combined somehow, though that would have to be more fine-grained than just the high/low they have now.

Generally speaking, I think that it is a good idea to allow web developers specify priorities in fine-grained manner. Therefore, IMO it would be beneficial to define (or suggest) how Priority Hints would be converted to the Priority header, even if it remains just to be "high"s and "low"s. That would help us gain consistency between the browsers. At the same time, I agree that the most preferable way would be let users specify in the HTML tag the values to be embedded in the Priority header.

I'm also not sure the mapping you propose is something we would want Kazuho: importance="high" suddenly making an image blocking feels to coarse (don't think that's what currently happening in the Chrome implementation).

I'd appreciate it if somebody familiar with Chrome could clarify the exact mapping, but I think that generally speaking, the mapping from the importance attribute to the value of Priority header would (should) depend on the type of the resource.

Consider the case of a CSS file that block rendering. The default urgency is "blocking." For such a resource, I do not think that having "importance" set to "high" ending up lowering the urgency makes sense. Therefore, the mapping of "importance=high" should at least be "urgency=blocking".

OTOH, I do agree that mapping of images with "importance" set to "high" should not be as high as "urgency=blocking", because there is no point in serving an image before serving the img tag that refers to the image.

WDYT?