A browser API to enable developers signal the priorities of the resources they need to download.
Home Page: https://wicg.github.io/priority-hints/
License: Other
Priority Hints provide developers with the control to indicate a resource's relative fetch priority to the browser.
Please see the Explainer & FAQ for long form feature explanation, goals, and reasoning.
See Examples section of the Explainer to see use cases of priority hints.
Given what the spec says:
This specification is no longer relevant and has been merged directly into the [[FETCH|Fetch]] and [[HTML|HTML]] specifications.
is it ok to archive this repo and label it as a successful incubation?
While crawling Priority Hints, the following links to other specifications were detected as pointing to non-existing anchors, which should be fixed:
This issue was detected and reported semi-automatically by Strudy based on data collected in webref.
importance is currently spec'd to apply to the element but it's an all-or-nothing approach. If a design has an image in the viewport for desktop but is hidden in mobile layouts then a site needs to make a judgement call on if it wants to always boost the priority or not.
I've never used it that way (and haven't yet verified that it works in Chrome or other browsers) but it appears that preload supports the media attribute which should allow for boosting the importance of an image explicitly with a media query (just requires preloading the image and can't be scoped on the image tag itself.
If this is the way we want to recommend people use priority hints (and preload in general) with responsive designs, it is probably worth having an example demonstrating it and making it clear.
Another use case for priority hints I've heard recently is to de-prioritize fetch() and cache.addAll() calls in a service worker install event. This could help avoid the background installation of many resources from starving out any requests initiated from the active window on the main thread.
Just FYI in case this is worth including in the list of use cases in the spec.
I started playing around with an implementation, and having 3 different attributes raises the question of "what happens if multiple attributes with conflicting values are defined?"
It's also cumbersome to implement and feels kinda clunky...
What if we changes that so that the group attribute would be of a "prefix_group" format, e.g. before_critical, in_visual, after_functional?
It would certainly make the implementation cleaner, and I think usage would be simpler as well: one attribute to feature detect, etc.
WDYT?
We recently introduced the concept of render-blocking. Since marking an element as render-blocking indicates that the resource is important, it does not make sense if we fetch the resource with a low fetch priority.
I'm going to put up a PR about this. The basic idea is that if an element has both fetchpriority=low and blocking=render attrbutes, then we'll ignore fetchpriority=low and fetch the resource with auto priority.
(Tested with the origin trial on Chrome 74.0.3711.0)
I noticed, that despite being loaded late, a favicon defined like this in the head:
<link rel="shortcut icon" href="/favicon.ico"/>
Will result in a "high" priority in devtools.
Adding importance="low" to the favicon link doesn't have any effect on that, it still shows up as "high".
As part of the Chrome origin trial, a fairly common question was "what effect does priority hints have on lazyload?".
It doesn't (directly anyway), but maybe instead of a separate importance attribute we should just extend the enumerations for the loading attribute to also cover priority hints and extend it to the other elements where lazyload doesn't apply (just making lazy equivalent to eager for those elements).
Something like:
| Keyword | State | Priority | Description |
|---|---|---|---|
| urgent | Eager | High | Used to fetch a resource immediately with high priority. |
| eager | Eager | Normal | Used to fetch a resource immediately with default priority; the default state. |
| idle | Eager | Low | Used to fetch a resource immediately with low priority. |
| lazy | Lazy | Normal | Used to defer fetching a resource until some conditions are met. |
It would be backwards compatible for browsers that support lazyload but not priority hints since the default value for unrecognized values is eager.
Extending the loading attribute also makes it very clear that the prioritization is limited to the loading of the resource (another often confusing point around importance). It is also a bit shorter which could help with #35 and it keeps the explosion if attributes under control.
At the fetch layer, the same attributes could also make sense on a loading attribute for the Request with the exception of lazy. That should be clean spec-wise though since lazy impacts the time when the fetch is initiated and isn't an attribute of the fetch itself.
When indicating a priority on a <link rel=preload> we don't want that priority overridden when the resource is later discovered:
group=late and font discovery should not upgrade that resource's prioritygroup=critical and image tag discovery should not downgrade that.group=lateRight 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?
I appreciate that importance is just a hint. That said, I'm struggling to see why the following code, within <head>, is not making any difference to the loading priority in Chrome 98. In Network Tools the priority remains stubbornly "Low".
<link rel="preload" as="image" href="https://turbo.freevideogamesonline.org/core-images/preloaders/jetpac-loader.gif" importance="high" />
The image is implemented on the page as...
<div id="game-container" style="background-image: url('https://turbo.freevideogamesonline.org/core-images/preloaders/jetpac-loader.gif'); background-repeat: no-repeat; background-position: center;"></div>
What are we doing wrong?
The site can be tested at https://freejetpac.org, but in case we implement any changes or workarounds before this message gets read, please use the following archive link:
https://freejetpac.org/index-priority-hints.php
Thanks in advance
At the Web Perf WG call today, it seemed that one of @toddreifsteck's more prominent hesitations revolved around the notion that Priority Hints might be trying to shift priorities among the many and different types (destinations, really) of resources. For example, a concern would have been "Well would a high importance image get prioritized higher than a low importance CSS file? And what if it did in Chrome but not Edge? etc." This sounded a bit like the original intent of Priority Hints (I recall group names and #7 (comment), which seems solved by specifying and emphasizing relative importance). I think a breakthrough we had in the conversation was when we mentioned that the prioritization of resources should be relative between types/destinations. For example, no matter what prioritization scheme might be used in Edge vs Chrome vs FF vs Safari, low-importance images should be prioritized lower than other non-low-importance images. The same goes for scripts, fetch()es, etc. Modifying the priority of a request relative to other requests of the same type definitely seems like something we'd like to make clear(er).
Assigning this to Addy right now as he's been digging around the spec quite a bit lately, but happy to pick this up if needbe after some more implementation work.
(aside from the main point of this issue:)
Another very reasonable hesitation we got revolved around the fact that it might be helpful to fully specify exactly how a resource gets prioritized, and some of the surrounding infrastructure, values, and logic so we could have this work dependably between the different implementations. While this is very valuable, I (and I believe @yoavweiss) think that Priority Hints would actually be a good step to getting us there, and is not a blocker so much as a catalyst to that conversation (which there has been some, albeit not tons, of talk around). For example, by talk about how importance=high async scripts should be prioritized higher than importance=low async scripts, we're already making relative comparisons that the Fetch Standard does not yet talk about.
The draft talks about a now-defunct prioritization scheme from HTTP/2, but does not talk about its replacement at all.
(Sorry, I had to make the title parallel #35.)
The abstract should say what the specification achieves (or hopes to). It currently says essentially nothing.
Is there a reason why this attrbute is called importance and not priority? E.g. could resources not be equally important but prioritized differently?
I realize "importance" in this sense refers to how to treat a resource, and not how important a resource is to e.g. site functionality. To me the priority name is more self explanatory.
Trying to summarize a few discussions before filing PRs:
importance attribute instead of group. Related to #6critical, high, medium, low, unimportant #7importance in terms of fetch.". Perhaps we should just reference that issue or another to encourage continuing that discussion.These are notably absent.
The intent might be inferred from the supporting text, but it would be good to have it in writing.
I assume that the only specified processing here would relate to the way that the provided "importance" value is taken and carried along with associated fetches. That is, the browser will take the value and hold it until it needs to make a prioritization decision, whereupon it can "use" the value in some unspecified way.
Is this available for origin trial in Chrome for Android? If so, which version started supporting it? I can't find a support gird anywhere.
This falls into the buckets of things that are probably going to be covered by virtue of the existing placeholders for the Fetch API usage examples, but I wanted to make sure that whatever solutions are proposed end up taking a specific use case into account: control over priority for requests used to populate caches inside of a service worker's install handler.
The most common way of doing that is not to use the Fetch API directly, but instead to use the Cache Storage API's add() or addAll() methods. Those methods can take in Request objects as parameters, in the same way that the Fetch API can.
So it would be preferable if the mechanism for indicating priority where associated with the Request interface, and another something directly tied to the Fetch API's fetch() method. I'm not well-versed in the language of specifications, but it seems like extending https://fetch.spec.whatwg.org/#request to include:
interface Request {
... existing fields ...
readonly attribute RequestPriority priority;
}
dictionary RequestInit {
... existing fields ...
RequestPriority priority;
}
enum RequestPriority { "placeholder1", "placeholder2", ... etc. };
would be sufficient. The placeholder values would correspond to whatever strings are agreed upon in #7
I'm happy to file this against the Fetch API spec eventually, but it seems like that might be premature at this point.
It seems like LinkedIn added a scheduler to Ember in order to avoid low-priority resources from contending on bandwidth with high-priority ones.
To quote their blog post:
"The second library we made available was a scheduler. Many teams had what they considered to be less important content, even within the viewport, that could be deferred until the initial view was fully interactive. They had been employing various hacks, like timeouts, that were set to be longer than what they thought was the longest reasonable load time. However, in some cases the deferred content was interfering with the initial render and causing re-renders as it was injected into the DOM. So we created a scheduler for a logical queuing of deferred content—this was content that was guaranteed to load after the initial render was complete."
Hi all! We the TAG reviewed this at our face-to-face meeting in Seattle, as per the issue you left in our repo.
Overall, we see a lot of good uses for this feature -- especially for something like a photo gallery, where you want to see the main photo first but may have to wait for thumbnails for all the other photos to load first.
But we are particularly concerned about the possibility that advertisers will say "In order to work with us and serve our ads, you must mark our ads as high priority" -- which really isn't in the interest of the user who was primarily asking to see the content of the page.
Have you thought about this?
We wondered if dropping iframe from your spec would solve that; but the same bad behaviour would be likely to persist with ads as images.
We also thought about dropping the high priority (leaving only the low and auto) -- which would only let the site mark certain resources as low. But it would still be possible for a coercive ad network to say, "To contract with us, you must mark all other content on the page as low-- except our ads." (Is that likely? Would a large content publisher actually be willing to do that? It feels less likely to me... but then, it probably depends on how much money is at stake.)
We did discuss the fact that the user agent could ignore the hints altogether, by setting or by an extension; though that would require users to know what's going on and to understand how to change it.
What do you think about this? Have you considered it, and if so, what is a good way to minimise the chances of this degrading the web experience for our users?
Would it be possible to use integer values instead of "low" and "high" importance? My use case is as follows:
We are building an OpenGL game world in which it's possible to calculate distance from the player to various resources in the game world. We would like to queue those resources (texture files, mesh files, etc.) to be loaded such that the nearest resources are loaded first, then a little farther out, and a little farther out, and so on.
We use THREE.js, and its underlying image texture loading is done by creating an "img" tag, then setting the "src" attribute to a URL.
Something like this would be perfect in our situation (programmatically added, of course):
<img src="/assets/nearest.png" importance="99">
<img src="/assets/near.png" importance="252">
<img src="/assets/farther.png" importance="305">
<img src="/assets/wayoutthere.png" importance="1090">
These integer values, in combination with Priority Hints, would allow us to help the our game queue up images to load in order of proximity (i.e. Math.sqrt(x^2 * y^2)) without loss of significant information to the browser.
Not sure if this is useful or not, but I requested the AMP team to whitelist your attribute while I beta test it. See the github issue: ampproject/amphtml#21945
I know your spec says we can add the importance attribute to:
Would you ever consider adding it to <amp-img> as well so we can use this API on the images in the AMP-HTML as well.
I've started work on the ReSpec version of the content in this repo. I've ported over all of the initial content and now need to update it to match #14 and #17. Will push to a branch soon.
Some notes as I work through:
importance or priority) rather than fetch classes. We will stick (for now) with three values for this initial proposal (high, lowanddefault`). This will require all the examples to be updated.Link header.. Link: <https://example.com/other/styles.css>; importance=high; as=style?<link rel=preload>? We've had a few questions about how these pieces are connected.While answering questions on the TAG review, it seemed like the usage examples have moved from the explainer to the spec itself. While it's important to have them in the spec, it seems equally important to have them as part of the explainer. We should probably copy them back.
I'm struggling to understand the intention behind the signals in the specification:
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.
After chatting with @domfarolino today, an item we noted would be useful for the explainer is the safety of using priority hints.
importance and (2) in a browser that does not.Given whatwg/html#3670 (comment) ... should we archive this incubation?
The developer tools aren't standard, but we should probably mention as a note somewhere mentioning:
It is encouraged that a browser's developer tools, where possible, communicate the effect of an importance attribute on the computed priority of a resource as network information
Again, it's far from mandatory, but seems worth throwing in since it's something most browsers can do and might make DX a little better?
On line 287 (the end of the first code sample in the Examples chapter), you accidentally omitted the </pre> to close the code sample. This happens to work (for a given definition of "work" - the entire rest of the document is parsed as "raw" by Bikeshed's markdown parser, which means zero markdown features work for the rest of the document; luckily HTML's error recovery means the </div> causes the <pre> to auto-close so the rest of the doc isn't monospace), but is definitely wrong, and while I was fiddling around in that section of Bikeshed's code I happened to trip over this.
I'll also note that all your code samples appear to be written assuming that you're working with raw HTML, as well, with the code undented to the left margin and with manual <br>s added. None of that is necessary; you can keep your <pre>s and their contents indented to the normal level for whatever section you're in, and Bikeshed automatically removes any common indentation for you. You could also switch to <xmp> and avoid having to escape anything.
That is, instead of the current spec's markup like:
<div class="example" title="Example 1">
<p>FastCorp Inc. have a carousel of images at the top of a page with the first image visible and the remaining images
images off screen. The markup of this carousel may look as follows:</p>
<pre highlight="html">
<ul class="carousel">
<br/> <!-- The first image is visible -->
<br/> <img src="img/carousel-1.jpg">
<br/> <!-- The other carousel images are not -->
<br/> <img src="img/carousel-2.jpg">
<br/> <img src="img/carousel-3.jpg">
<br/> <img src="img/carousel-4.jpg">
<br/></ul>
</div>you could be writing:
<div class="example" title="Example 1">
<p>FastCorp Inc. have a carousel of images at the top of a page with the first image visible and the remaining images
images off screen. The markup of this carousel may look as follows:</p>
<xmp highlight="html">
<ul class="carousel">
<!-- The first image is visible -->
<img src="img/carousel-1.jpg">
<!-- The other carousel images are not -->
<img src="img/carousel-2.jpg">
<img src="img/carousel-3.jpg">
<img src="img/carousel-4.jpg">
</ul>
</xmp>
</div>which, in addition to being easier to read and write, is also much more obvious that you've left out the ending tag.
The Examples file mentions importance=critical and importance=medium but the proposed spec (https://wicg.github.io/priority-hints/) only mentions setting importance with either high or low.
Should EXAMPLES.md be updated to reflect the latest spec?
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.
This follows a Twitter discussion with @zcorpan. Here is the full thread in one place.
This is a suggestion to discuss the opportunity to let developers define multiple values for importance based on Media Queries, like we do for the responsive images.
I see at least 2 use cases:
<picture><source media>, the importance can vary based on Art Direction<img srcset sizes>, the importance can vary based on layout changing across viewports, an image being above the fold on large viewports but below on thinner viewportsFor the first use case, we would need to allow using the importance attribute on source elements (as we need for the alt attribute).
For both use cases, the syntax could be the same as for sizes: importance="(min-width: 50em) high, low".
To ease using multiple times the same Media Queries in <source media>, sizes and importance, we could suggest developers to use custom MQs, as suggested by @zcorpan.
I talked about viewport based Media Queries here, but some other Media Queries might be useful too.
Considering how much this might show up in HTML, APIs and HTTP headers, can we come up with something shorter?
Especially HTTP headers, where HPACK/QPACK won't be able to offer a lot of benefit (as there will be a lot of entropy in the link part of the header, presumably).
Both <script> and <iframe> DOM elements can trigger a lot of resource requests. It's true we don't have a real processing model in this document, but we should still probably define here what effects the importance value given to a top-level <script> or <iframe> will have on their requested subresources. Note: this is different than the dependency graph request prioritization of a module script which is outside of the scope of this discussion.
Here are a few questions:
importance value as their parent?In other words, should every request made in the below example all have importance = low
// index.html
<iframe importance=low src=doc.html></iframe>
<script importance=low src=main.js></script>
// doc.html
<img src=https://image.here alt=image>
// main.js
fetch("https://domfarolino.com")
This definitely seems logical to me to get the most benefit out of the Priority Hints effort.
importance values?In other words, what are the resolved importance values of all of the below requests:
// index.html
<iframe importance=low src=doc.html></iframe>
<script importance=low src=main.js></script>
// doc.html
<img importance=high src=https://image.here alt=image>
// main.js
fetch("https://domfarolino.com", {importance: high})
I'm not sure what the best call to make here is. In my opinion, the two best options are:
importance values, they should just assume that of their parent<script importance=low src=main.js>
// main.js
let link = document.createElement('link');
link.importance = 'high';
link.......
.....
document.head.appendChild(link);
I'm not even sure if we could bully-down the added element's priority based on who added it to the DOM, but I don't think we should do that in this case. IMO I think it would make sense if the <link>'s ultimate importance was high here.
...more example? Thoughts?
I assume it would be good to specify this in the document so people can see how far-reaching and influential an importance value is on these types of elements.
After talking to the Ember team about priority hints, they indicated we're currently missing a mechanism for informing developers when a particular fetch-group/importance group has completed loading.
Chatting with @yoavweiss at TPAC, it may also be possible to add a change to resource timing that allowed us to track when new resources are being added.
Specifications like this need very careful disclaimers.
An important disclaimer here is that priority is something of a zero-sum game. Marking everything as high priority is likely to make performance worse overall. That is, priority is about moving one thing out of the way for another.
This might seem like an obvious thing, but I've heard enough stories to know that people are prone to the sort of magical thinking that leads to slapping importance="high" on every load.
After speaking to Kenji about the syntax for Link header support, he was proposing we add a mention for:
Link: <https://example.com/images/hero.jpg>; rel=preload; as=image; importance=high
While working on https://chromium-review.googlesource.com/c/chromium/src/+/678216 a few questions came up:
Thoughts?
For battery powered devices, it seems reasonable to me to use importance as an indication of whether a fetch can be deferred until a radio power up is required by some other, higher priority fetch. Would you consider indicating in the spec here that, as a general principle, importance may be used by UAs to affect not just the order of fetches. In #23, there's a use case for triggering a resource to load on an event that's not expected to occur for some time. This is potentially a similar situation.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.