Consider lowering the number of values

[yoavweiss]

Feedback from the WebPerfWG TPAC F2F: A smaller number of values can probably satisfy the use cases and make the feature more predictable from an interoperability perspective.

[addyosmani]

IIRC, the feedback from TPAC was that we might be able to deliver on the main value proposition with as few as two values: low, high. I believe it was also noted that if we needed more keeping it to under 5 would be desirable as what we've got right now would be too many.

[addyosmani]

@yoavweiss As a strawman, I would like to propose we spec low, medium and high as the possible values for the importance attribute. Happy to discuss with other vendors whether this would satisfy their desire to keep possible values to a minimum.

Usage example for a single-page app that also contains ads and a logo for branding:

Three values

<!-- Core logic for the application -->
<script src="main.js" importance="high"></script>

<!-- Resources that can be loaded much later -->
<script src="non-critical.js" importance="low"></script>
<script src="ads.js" importance="low"></script>

<!-- Branding: slightly more important than non-critical JS -->
<img src="logo.png" importance="medium"/>

Two values

<!-- Core logic for the application -->
<script src="main.js" importance="high"></script>

<!-- Resources that can be loaded much later -->
<script src="non-critical.js" importance="low"></script>
<script src="ads.js" importance="low"></script>

<!-- Branding: treat as important as the core bundle -->
<img src="logo.png" importance="high"/>

Talking to some teams at Google, three possible values would provide sufficient control as long as it's deferred to the UA what the relative mapping for these priorities are.

Interested in other folks takes here.

cc @wanderview @rniwa @nolanlawson

[yoavweiss]

SGTM

[rniwa]

Instead of "medium", we should call it "normal" or "default" assuming that's the default value.

[evenstensberg]

Maybe instead of the attribute importance, sticking with priority would be better?

Even though important(cy) is used more commonly in the english language ( from user POV ), it may be confusing and indicates a boolean value. priority indicates 3 levels, high, medium and low.

<script src="space.js" priority="low" />
<script src="x.js" priority="medium" />
<script src="f9.js" priority="high" />

To extend this, maybe we can support touples like:

<!-- Core logic -->
<script src="f9.js" priority="low" />
<script src="f9.js" priority="high" />
<script src="x.js" priority="medium" />

<script src="f9.js" priority="medium low" />
<script src="x.js" priority="high medium" />
<script src="x.js" priority="medium high" />
<script src="f9.js" priority="low medium" />
<script src="f9.js" priority="low high" />

With this approach, we can either:

1. Allow touples
2. Allow "unlimited" boundaries ( i.e 10 sublevels or similar )

By "unlimited" boundaries, I mean that we can for each label ( high, medium, low) prioritize within those label themselves. Consider:

1. a.js should be loaded before b.js, but its a medium priority. When we allow unlimited nesting, we allow fine-grained loading patterns as well as avoiding introducing extra labels.

For browser vendors, this would be reading all tags on parsing, followed up by looking at the max number of labels w.r.t every node, and then creating "categories".

So if we divide into 3 categories and substract the sub-labels from the main category:
<script src="f9.js" priority="low low medium" />

low (33% important) - low (11% important) - medium (7.3% important)

total importancy for f9: 33-11-7.3 = 15

Another way to think about this is that we split up the requests into subsets of a category, prioritizing with the three labels. Then we gradually send the requests. So if we've got low medium and low high, medium low and medium high, we start with medium high, go to medium low and then do the same for low ( with its subsets )

If I made myself unclear, happy to elaborate!

[domfarolino]

@ev1stensberg Thanks for the input! Personally I could go either way on importance vs priority, but it seems like importance is a more user-appropriate value as we're really indicating the importance of some content to the page, in hopes that the browser will take it into consideration when computing the request's eventual priority.

If we were to use priority as the attribute, it would give the appearance that user-facing priority is equivalent to browser resource-scheduling priority which simply isn't accurate given:

• All of the things taken into account to create a priority
• The intentionally weak language the spec uses to indicate to the reader that using the importance simply "hints" at the intended priority, but isn't an "instruction" for the browser.

---

Regarding the support of tuples, it seems that vendors and others have pushed for the minimization of values (and we've decided on "low", "auto", and "high" for now), so I suspect adding more complexity and different weights to each value in a tuple (and spec'ing this out!) to indicate an overall "importance" value would be frowned upon, but perhaps we should ask around? Thoughts?

Barring these potentially open questions, this issue might be able to be closed as the current spec reflects the aforementioned three values.

[addyosmani]

+1 @domfarolino

I just wanted to re-iterate that I'm strongly in favor of attempting to minimize the complexity of the initial version of the API, punting to a more advanced/granular control model over time as and when vendors hear feedback from developers about where importance with a small set of values isn't working out.

I certainly think there's room to explore and evaluate more complete models as time moves on, but concern with tuples approach today is that it's I don't think we'll be able to get vendors on-board without demonstrating the simpler model offers developers real value.