Relative or absolute

[martinthomson]

I'm struggling to understand the intention behind the signals in the specification:

• high - The developer considers the resource as being high priority.
• low - The developer considers the resource as being low priority.
• auto - The developer does not indicate a preference.

There are a number of ways that you might interpret these and that interpretation will affect how sites need to construct the values.

Whether the values are intended to be relative or absolute is perhaps one of the more important questions. If a resource that is ordinarily low priority is marked with importance="high", does that make it high relative to other requests of its type, or all requests that are currently active?

For example, a rel="preload" for an image might get placed in the lowest prioritization class; setting importance="low" might not go any lower, but how far should a developer expect importance="high" to move it up? If "high" was absolute, this might place that load up with inline scripts; whereas a relative shift might lift it to the level of in-viewport images (or something else, according to the proprietary algorithm that client uses).

The question of relative vs. absolute is relevant in how you interpret "auto" also. "auto" might be interpreted as "normal", with a relative increase in priority for "high" and a decrease for "low". On the other hand, already high priority content might treat an absolute signal of "high" as equivalent to "auto", with a signal of "low" being the only value that has an effect. Absolute values are perhaps most interesting for content that is fetched with middling priority.

[pmeenan]

Thanks. I'll get a PR in flight to clarify it for tomorrow, but the intent is for the signals to be relative to the resource type, not absolute on any global scale. i.e.

• "This is a high-priority image" means relative to how an image would normally be treated.
• "This is a low-priority async script" means relative to how an async script would normally be treated (in Chrome for example, async scripts are still higher priority than images by default).

There isn't an expectation that a developer would, or even should, be able to lay out a global explicit ordering. Just provide nudges that the browser could choose to use while still accounting for tree-building-blocking scripts, etc.

[martinthomson]

Sounds reasonable. Thanks.

I do have to ask why the choice of "auto" rather than "normal" here? Are you looking to avoid the implication that "normal" might not imply "normal for the type of resource in the specific circumstances"? Or are you trying to impress upon developers that browsers behaviour with respect to prioritization is magical/inscrutable?

The next question is whether there is an expectation that "high" or "low" moves the needle from the default or if the UA is given discretion in that.

Obviously, there are ways in which a change might not be obvious or testable:

• if the resource is already at an extreme, it can't get more extreme

• if the browser creates finer graduations of priority than it might signal (via a somewhat constrained u=0-7 range say), it's possible that a change doesn't result in any obvious change from the perspective of the developer

It might help to include some text that explains these subtleties. But if there is some expectation that "high" > "auto" > "low", that would be good to have in writing somewhere.

[pmeenan]

The general direction was for "auto" to let the browser's heuristics decide on the importance of the resource using its own heuristics.

If it helps (and I'll also add clarification to the spec), here is Chrome's priority table and the effect "high" or "low" have on each resource type.

As a concrete example, Chrome will default to assigning blocking scripts an initial high priority if they are early in the document and a low priority if they are late in the document (boundary between early and late being a parsed image tag in the document). Priority Hints will let a dev be explicit about shifting the initial priority of either. In all cases, as soon as the tree builder reaches a blocking script it will boost the priority to high, independent of any other heuristics or hints.

There's definitely not the expectation that "auto" is necessarily a 3rd level between "high" and "low". In some cases it might make sense for it to be, like with explicit fetch API calls, having "high" boost the priority and "low" lower the priority. In Chrome, at least for now, fetches are always "high" by default so "low" just gives a way to lower the priority of a background task.

[martinthomson]

So now I have a different question: in those cases where the default behaviour is changing or dynamic (starts low, jumps to high when it blocks, for example), what is the implied meaning? Does "high" affect the low starting priority, causing it to be higher than the (low) baseline, without jumping to the blocking priority you might get when a script might call document.write()? There are a few steps between a starting priority and that crash priority you might get for blocking content.

Similarly, does marking that script as "low" put it at the baseline level even after the browser has determined that it is blocking?

These are questions I'm not seeing clear and unambiguous answers to, either here or in #54.

Obviously you want to allow the browser some flexibility here, but expectations are all we have here.

Here's what I would say. "high" means higher than the browser logic would normally assign (and "low" likewise). Hence, a lower priority for a blocking script still requires the highest priority; fetches from background tabs never rise to the highest priority levels. The type of resource and its circumstances define a range of priorities that might be permitted for fetching. The attribute allows the developer to skew toward one or other end of that range.

[pmeenan]

For Chrome at least, the importance affects the initial priority that is determined at parse time. The dynamic changes happen as they would normally. If a blocking script is "low" (either explicitly by hint or by document position using heuristics), it will still get elevated to high once the tree builder is actually blocked on it (though, practically, that requires a cooperating origin that actually supports priority changes - getting it correct from the beginning is best).

As far as cross-tab prioritization for Chrome that is handled independently of individual resource priorities within a given tab and nothing with priority hints can, or should, change that.

The lack of clear, explicit lines between the markup hints and the underlying fetches is on purpose. All of the main browser engines have VERY different fetch policies and I don't expect them to ever align. That's why it is somewhat removed from actual priority and why "importance" was selected. "This is an important image", "this is a less important script", etc. There won't be a deterministic, consistent result across browsers because of the different browser priorities (rendering content early and often vs holding back and rendering as much as possible but later).

The signals from the hints can at least provide the browser heuristics more information than they would have otherwise but it's really just a hint/signal, not something with a direct outcome.