WICG/priority-hints

Use case: priority downgrade/upgrade should not be overwritten

yoavweiss opened this issue · 5 comments

yoavweiss commented

When indicating a priority on a <link rel=preload> we don't want that priority overridden when the resource is later discovered:

  • e.g. a font preload can indicate group=late and font discovery should not upgrade that resource's priority
  • An image preload can indicate group=critical and image tag discovery should not downgrade that.
  • At the same time, the UA can override hints which make little sense, e.g. render blocking resources with group=late
jakearchibald commented

What if I wanted the priority to change when the resource was needed? As in "Preload this script at a lower priority than these non-preloaded scripts, but switch to high priority once a script element consumes the preload".

addyosmani commented

I agree with Jake. I think developers will want request reprioritization as a capability for when there's more nuance available about why a particular preloaded resource was now more important than originally thought.

That said, at BlinkOn, I believe Kinuko expressed concerns about a V0 supporting the ability to change the priority of in-flight requests (complexity, is this too edge-case etc). I might be remembering this wrong.

kinu commented

I just worried about the potential complexity (that tends to make discussion go on forever) vs expected benefits. On the other hand I agree that there would be very valid use cases where we want to change priorities-- so I'm totally fine if we can possibly converge on how the priority should change in some specific concrete scenarios =)

If we allow priority overriding we probably want to make both cases (i.e. allowing priority to be upgraded at resource discovery time or not) configurable by developers? Say, do we need an additional attribute to specify that flavor?

Also: this is probably a bit orthogonal, but do we want to allow modifying group= attribute to be reflected?

pmeenan commented

I have a bit of history with downgrades from early on in Chrome's priority support for images and I think we're far better off if we leave the hint scoped to the element it is directly attached to and not extend it to cover other tags.

If there is a preload for a script that set importance=low and there is a blocking script tag in the html then the blocking tag would also need importance=low or else leave it to the browser to determine what to do with multiple requests for the same resource at different priority levels.

Chrome currently only allows for priority increases because of cases when there are multiple images in the page that use the same underlying image. If some of them are in the viewport and some are not we had a situation where the "high" priority of the in-viewport images was accidentally overwritten by the "low" priority of the out-of-viewport references to the same image.