Discussion

Priority Hints is an API that lets developers signal to the browser the relative importance of a resource to a page, 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 H2 priority, delaying when a request is sent out, etc.

Developers have expressed interest in an API that lets them guide the browser's native prioritization logic in cases where the developer might know better than the browser, which resources are more important to a page than others. The spec describes a new attribute named importance that can be applied to some resource-fetching HTML elements (as well as the fetch() API). The attribute can take the value of auto, low, or high, as currently denoted in the explainer spec. The attribute is just a hint, similar to image decoding. I propose supporting this importance hint on the following elements:

• <link>
• <img>
• <script>
• <iframe>
• ...others that make sense?

I'm owning the implementation of Priority Hints in Chrome, and it seems like it'd be good to try and gauge interest in this from other implementers and work on getting this standardized. IIRC, Priority Hints has gotten good feedback at TPAC, but @addyosmani can speak more for this.

/cc @addyosmani @yoavweiss @yutakahirano @bzbarsky @wanderview (other...?)

Spec Questions/Work

Assuming this seems like a good idea to the editors, I'm happy to lead the standardization effort of this both here and in the Fetch Standard. Here are a few questions I have at the moment regarding potential spec changes:

• It seems that the attribute can be spec'ed as an enumerated attribute with missing & invalid value defaults as the auto mode. Seeing as how it spans multiple resource-fetching elements, it seems like a good idea to include it in the URLs & Fetching section, like the CORS settings attributes, is this the right idea?
• (Also it seems it'll need to appear in the IDL of the list of supported resource-fetching elements that appear above, as well as their processing models where the importance can be communicated to the Fetch Standard)

• Subresources

  • We'd like the importance value of scripts and iframes to trickle down to their subresources. I haven't dug around enough myself, but if someone could point me to where in the spec we can acknowledge properties of the parent element of subresources that would be nice.

• Module Scripts

  • I know that loading modules has some different infrastructure, and preloading, due to this infra, was different-enough to warrant the creation of the rel value modulepreload, so I'm wondering what work will need to be done here in the fetching of a module graph.
• I'll can follow up with an issue on the Fetch Standard to determine what changes will need made there, so we can discuss that here and I can just submit a PR separately (since the changes should be relatively small compared to those here).