Group names bikeshed

[yoavweiss]

Right now the group names in the explainer are: critical, fonts, functional, visual and late.
There are not necessarily good names, and we need to come up with better ones.

As @jakearchibald pointed out, fonts is unlike the others as it says "what is this resource" vs. "when is this group fetched".
Maybe we can replace it with textcritical?

Otherwise, thoughts on the other names?

cc @addyosmani @KenjiBaheux @jakearchibald

[KenjiBaheux]

I imagine that we will have more rounds of bikeshedding but I agree we should start with keywords that are aligned in their intent.

Let's see:

If the point of Priority Hints is to allow developers to convey how important they think a particular resource is, then it follows that the keywords should be about the "how/when" (e.g. critical, late) and not so much about the "what" (e.g. font). In particular, the "what" seems easy to figure out from the type of resource, no?

Does it matter to convey the "why" (e.g. text, functional)? Is it something that the UA can reliably infer from the type of the resource?

Or perhaps the "why" should be about explaining why the UA should care (e.g. "render-blocking", "interactive-blocking")? I think there is value in a scheme that explains the "why should you care" as it should avoid ending up with developers putting "critical" on all the things.

Strawman: groups made of reasons and importance (e.g. "render-critical")

• reasons: render, interactive, ???
• importance: critical, important, unimportant

Hmm, perhaps "unimportant" should be allowed to be used without a reason?

Thoughts?

[kinu]

+1 to the points that mixing "how/when" and "what" would make things complex, or would give people wrong signals. I prefer we start with the term that clearly only indicates the importance, but am interested in what use cases would fall out if we do so.

[yoavweiss]

"reason/importance" makes sense to me. We probably want to add text to the reasons. We may also not want to add a "-" to the values in order to enable them as a signal for future custom fetch groups.

[jakearchibald]

I'm a little worried about going with "importance" rather than "type of thing".

Let's say I want one of my scripts to be lower priority than others. In order to fix that, I need to figure out which priority the other scripts implicitly have, and give it the priority lower than that. Let's say the values are 'low', 'medium', 'high' and 'critical', and it appears that scripts are 'high', so I pick 'medium' for this particular script.

As a developer, I'm having to translate from type to importance to get the behaviour I want. However, I'm aware that browsers experiment with priorities, and the default priority for scripts may not always be 'high'. That means my value that was intended to be relative to other scripts, may break in future.

To fix this, I assign priorities to all the other scripts. However, this may mess around with the priority of the scripts vs CSS, so now I have to add priorities to the CSS too, then imgs etc etc. In the end, if I want control, I have to assign priorities to everything.

[marcoscaceres]

To echo @jakearchibald, be really really careful with this (and maybe developer test it first, by getting a group of devs together and asking them to apply these labels to simple site just to see what they do)... we got burnt by this kind of thing in other specs: developers tend label things as "what it is" and not "what I actually want is...".

[addyosmani]

I'm concerned the current named fetch-groups are going to be a little unintuitive for a developer to reason about in the context of a modern webapp. Much of this comes down to the point of making it easy to reason about "when a group is fetched".

Let's walk through an example, say Twitter Lite, assuming I don't have knowledge of a browser's network stack or how priorities work:

• I have a stylesheet for the initial application UI. Although this is technically visual, I think it's important to the show the user something early so I'll assign it to the critical fetch-group. My assumption is critical > visual.
• I have a few scripts (auth, vendor) that are critical to booting up & rendering the login view for the app. I guess I'll group these into critical too. Although showing something on screen is important (styles), you aren't able to login unless they're fetched and processed. I'm not really sure at this point whether my styles or scripts will be loaded first. As an author, I'm now thinking I may need to A/B test giving these scripts a functional group.
• For branding, I have a Twitter logo image I'd like to load somewhat early on into the UI navbar. It's not critical and there doesn't seem to be a way to distinguish between what is visually text vs visually an image, so I'll group this into visual. As long as it isn't loaded late, we're good.
• I login. I have JSON data that will be needed to populate my stream of tweets. Once fetch supports priority hints, I guess I'd load this as critical.
• My JSON will also give me a list of image avatars for tweets. They're not really all that important, but I also don't want the browser to wait forever before loading them (late). I'll group images into visual.
• I have 20-30 other scripts I now need to lazy-load for other parts of the experience as the user navigates through. They don't all need to be loaded at once. They are not critical yet. Some of these will inject and render new routes. Some of these rely on scripts that are purely functional. I'm torn between whether these should be functional or late. I'd probably group them into late and try changing priorities to functional (assuming functional > late) if a user started navigating to a section of the app that usually required them.
• I have a Web Font that I use for emoji icons (hypothetical, Twitter actually uses SVGs). They're usually used for either authoring tweets or DMs. I honestly don't know how what the priority group of fonts entails - when will this thing be loaded?. This is technically not a critical resource, but also isn't something that should be loaded late. I'm worried the browser will consider my font something that can be loaded late so I'd go with visual.
• Videos and images embedded in tweets: I'll probably give media loaded within the viewport to the visual group and anything below the viewport a late. If the user scrolls I may switch the priority of earlier out of viewport content to late and content coming into the viewport as critical or visual.

In this case, I actually didn't mind needing to manually annotate my page using the different fetch-groups. I did run into a few cases where I was left guessing "when" a resource would be loaded. If the names could somehow reflect this better I think it could massively help minimize confusion.

[jakearchibald]

My JSON will also give me a list of image avatars for tweets. They're not really all that important, but I also don't want the browser to wait forever before loading them (late)

This is the sort of thing I'm worried about. The lower priorities feel really risky, because you're not sure what might be prioritised above them.

Maybe this wouldn't be such a problem if I was able to express "these images should have higher priority than these analytics pings".

[paularmstrong]

I looked around for a while and was surprised to see that the priorities weren't (nor were called out as a consideration to have been) number values. What's the reasoning to not use priority="100"? Indexing at a number value will avoid any of the confusion of "when does font load relative to late and visual?" It also allows for future growth in this area. For example, audio is not something that was considered. How do I define, as an app developer, that audio is more important than visual, but not critical? (There are cases where this may be the case.)

When looking at Twitter Lite, for example, @addyosmani is pretty spot on. The only thing that I'd add is that the priorities will need to change based on what the visitor's landing page happens to be. While vendor, main, and shared are all scripts that need to be loaded as critical, the order of other scripts may need to change, and not just between visual, critical, and late, but some may jump to functional... but now I'm confused, because what does that actually mean if I put something there?

Whereas if we were to use a numbering system, it might look like this:

• Priorities are indexed like z-index. Higher value means higher priority. This also should help the fetch mechanism provide real weights to requests.
• Default priority is 1. Items that do not define priority are loaded as they are seen.
• priority="0" is the lowest priority, similar to late: load this resource when there are free cycles and no network contention
• priority >= 2, will be loaded based on their priority weight; higher numbers are given more priority, etc.

[jakearchibald]

My concerns in #7 (comment) stand for a numbered system too.

A numbered system would be like z-index if every element without an explicit z-index was assigned one by the browser, and different browsers (and versions) assigned different values. z-index is pretty difficult to manage as it stands, but in this system you'd have to give everything an explicit z-index to have any kind of control.

[paularmstrong]

@jakearchibald Without defining a true priority, how do you envision you would manage cases where "type of thing" doesn't match with what the actual desired priority is (e.g. audible vs visual)?

In my experience, type often does a poor job of defining importance and I end up having to do a lot of work anyway to figure out which particular script/image/mp3/mkv/woff/etc is more important than something else. We're already splitting bundles into separate chunks, and we know their priority and can define them, but our systems don't and have a really hard time automating which one should be loaded first.

A numbered system would be like z-index if every element without an explicit z-index was assigned one by the browser, and different browsers (and versions) assigned different values

Why would browsers assign different default values? Do we just expect browsers to never follow standards, and therefore we shouldn't even try defining them?

[jakearchibald]

@paularmstrong

I end up having to do a lot of work anyway to figure out which particular script/image/mp3/mkv/woff/etc is more important than something else

How would this be different in a numbered system? Surely the only difference is you'd have to translate that particular script/image/mp3/mkv/woff/etc into a number, or assign one.

Why would browsers assign different default values? Do we just expect browsers to never follow standards, and therefore we shouldn't even try defining them?

The alternative is we say something like "scripts are higher priority than stylesheets", and compliant browsers would have to do that, even if, 10 years later, that turns out to be bad for performance.

I'm not sure our priority guesses 10 years ago would be the best choices for today.

[yoavweiss]

I talked to @pmeenan about the above and he proposed something interesting.
Instead of defining priorities for resources, we define their importance.
That way we can avoid "critical" images from being downloaded before "critical" CSS, or "late" blocking JS from blocking DOM parsing for long periods.

Browsers would be able to further experiment with those resources' priorities, while respecting their relative importance.

It is true that you won't be able to absolutely define a resource Y as "more important than type X", but in return browsers would be able to continue to experiment with resource priorities while giving developers enough expressive power to define their intentions (and won't cause the same confusion that @addyosmani described in his comment).

Defining such importance levels (e.g. critical, high, medium, low, unimportant) would allow us to address Addy's use cases with ease:

• The UI stylesheet would be marked as importance=critical, as well as the boot-up and render scripts. The browser will still probably assign higher priority to the style than to the scripts, but that's perfectly fine.
• The logo image importance may also be tagged as critical or high. The browser will bump up its priority, but not to an extent that it delays download and execution of styles or blocking scripts.
• Marking the timeline JSON as critical will also clarify to the browser that this is one of the most important fetch() triggered fetches, and will help it prioritize it accordingly.
• The avatar images can probably be of medium importance.
• Lazy loaded scripts are probably also of medium importance, unless user gestures indicate that they'd be needed soon, bumping them to critical.
• Icon font can probably be marked of medium importance as well, while a potential font preload (for a font that's responsible to render large chunks of visible text) will be marked as critical and will likely download right after the critical styles and scripts.
• Media inside the tweets would probably be medium or low importance, while everything below the fold, can probably be marked as unimportant.

[kinu]

Specifying importance sounds good to me, and seems to resolve some of the issues that were pointed out so far. One of the potential downside would be that it wouldn't allow developers to give some ordering or dependency hints over multiple types of resources, but maybe it's still just okay as they can still give indirect hints by giving different priorities? I'd like to hear how other developers might feel.

[addyosmani]

Instead of defining priorities for resources, we define their importance.

I like the idea of defining importance and ensuring browsers can keep adjusting resource priorities independent of the hinting control we offer developers. I don't think we lose that much without being able to specify as strong a relative mapping with "X is more important than Y". I'd be curious to hear @igrigorik's take on this too.

My main concern with defining importance levels with the suggested labels (critical, high, medium, low, unimportant) is the guarantees they might imply. These labels aren't too far away from the network priority names we use in Chrome (high, medium, low etc) and might come across as more of a "we're guaranteeing you'll be able to specify this importance and the browser will have to respect it" vs a hint. I felt "fonts", "functional", "visual" and "late" didn't quite set this expectation, but.. I might be overthinking the naming here.

Perhaps it's fine for us to keep a very similar nomenclature to the existing priorities and setting expectations is more of a docs/advocacy issue. I could see developers understanding critical, high etc. without too much explanation otherwise.

[KenjiBaheux]

I'm supportive of the idea of conveying the importance as I initially indicated. We can refine the keywords to avoid confusion with existing network priorities expressed in browsers.

Re: ordering and dependencies. I think these are out of scope for this proposal. Priority-hints (hmm, Importance-hints ?) is meant for use cases centered around independent resources (e.g. this async script is actually critical for a fast render, this image is actually the primary content of the page).

With ordering and dependencies, the UA would need the full picture to properly fulfill the developer's intent. This suggests a different API. Perhaps, a loading manifest ?

[addyosmani]

As we've converged on importance as the name of the attribute, both for declarative and imperative use-cases I think it's okay for us to close this issue. We can re-open or file a new issue if we find there's vendor push-back on the current naming (there hasn't been so far).