Priority Hints has been in origin trial in Chrome for a couple of months at this point and the developer feedback is summarized here.

The feedback is all extremely positive with a lot of excitement for launching it beyond a trial. There were challenges for some sites with the origin trial framework itself but none with the actual feature. Most of the developers experimenting with it right now are using it to boost the priority of important images (and to improve the largest-contentful-paint in particular).

• Very easy to use and integrates well with picture, srcset and sizes (which is very difficult to emulate when using preload for similar purposes).
• Decent performance gains for some sites that ran field trials, even for already highly-optimized sites.
• For everything except for scripts, there aren't good ways to get similar effects. Resrtructuring the entire page and using preload liberally can get close but is very difficult to get right and to work well across browsers.

On the standardization front, we have been bikeshedding on the feature for a few years in the web performance working group. The two common areas of contention are:

The level of control over prioritization

Some would like more fine-grained control over fetch ordering and prioritization (lots of explicit levels, direct linkage to the underlying protocol priority support). The current disconnect from explicit prioritization is intentional and gives developers a level of control that aligns with what browsers, protocols and origins are actually able to support reliably.

Labeling images/scripts/frames/fetches as "more" or "less" important provides the hinting that browsers need that isn't organically available otherwise and is easy for site owners to understand without being overly complex (or opening up too big of a footgun).

The attribute name

importance is the attribute that we landed on after LOTS of discussion and aligns well with the concept of "this is an important image" or "this fetch is less important".

• There are some concerns about the length of the attribute name but the values themselves are very short (high, low, auto) and when combined together, the resulting string length is in line with any other alternatives.
• importance is quite generic for something that is restricted to the fetch priority of the main resource for the relevant element.
  • We considered extending loading which is currently used for lazy-load but the existing "lazy" and "eager" attribute values don't work well when combined with importance values.
• There is concern that we are exploding the attributes on elements in a way that makes it more difficult for developers.
  • We toyed with the idea of moving fetch-related hints into a fetch attribute but then it just moves the cognitive load to decoding the string parameters within the fetch attribute and doesn't actually make things any easier.

At the end of the day, importance=high/low/auto is the cleanest we could come up with for developers to indicate the importance of elements of similar types and for that importance to only manifest in the fetching of the resource needed for that element. If, at some point in the future, we need a way to control the execution time of a script or the scheduling priority of tasks in an iframe, those would likely need something more explicit than an attribute with the name importance.

One question: can you let us know where this work is headed AFTER incubation in WICG please?

Once there are 2 browser implementations, into the HTML spec for the attribute additions to img/script/iframe/link tags and into the Fetch spec for the enum property added to the JS request API.

FWIW, the spec has an HTML section that includes references to the relevant changes to the HTML spec and a Fetch section with the relevant fetch spec changes.

There are already issues filed with the HTML and Fetch specs as well.

As far as browser implementations to pass the 2-engine threshold, Chrome will be launching whatever ends up getting a thumbs up (in case the attributes change) and Mozilla appears to be positive towards the feature. No word from webkit yet but their internal prioritization is similar to blink's and should benefit from it as well.

We discussed this in today's call. We think the feature itself is pretty good as it stands. One concern that we had was advertisers forcing themselves to high priority, which I believe can happen with modern day ad serving methods (and likely will) - please consider potential mitigations for this potential risk.

Otherwise, we are happy to see this move forward, and thank you for bringing this to our attention.

Thanks. The sites can control the priority of the initial ad logic/script which should mitigate the bulk of the issue. An ad may be able to boost the priority of downstream script fetches or any iframe documents that it adds to the page but at that point it is after the initial ad script has already loaded and run, reducing any likely risks. It may actually be beneficial even within an ad context to prioritize images and scripts relative to each other.

I'll bring it up with the working group to discuss if it might make sense to look into possible CSP rules preventing the API from being available in 3rd-party script contexts which would give a site explicit control over what would be able to apply hints but that might be overkill.

It may actually be beneficial even within an ad context to prioritize images and scripts relative to each other.

This would make sense, but at the same time it feels like it should be tiered (main content high > ad content high) and controllable by the top level document. I'd imagine ad banners would ask for high priority once they know this feature exists. (And the last thing the user would want is ad banners to be served before actual content...)

Assuming the ad content is triggered by script, main content high will come before ad content high in the vast majority of cases because of discovery order. The page also controls the timing/priority of the initial ad script which is the main lever for controlling ad code execution.

Browsers also have control over same-origin vs cross-origin that they can layer on top of the importance signals if necessary and already consider frame vs main document when scheduling fetches.

I think there's a fair amount of control already in place where non-hostile ad scripts will still prioritize appropriately and a good case for why the hints aren't hard-wired to explicit priorities.

An extreme case where an ad script agressively rewrites other page content would be a problem but that's the case generally and not specific to priority hints.

On Mon, Feb 14, 2022 at 10:50 PM cynthia @.***> wrote:

It may actually be beneficial even within an ad context to prioritize images and scripts relative to each other.

This would make sense, but at the same time it feels like it should be tiered (main content high > ad content high) and controllable by the top level document. I'd imagine ad banners would ask for high priority once they know this feature exists. (And the last thing the user would want is ad banners to be served before actual content...)

— Reply to this email directly, view it on GitHub https://github.com/w3ctag/design-reviews/issues/704#issuecomment-1039825142, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADMOBNPOXXXIOFJJSLJN43U3HEO5ANCNFSM5K2XIMAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

@cynthia, @torgo

FYI, the bikeshedding on the attribute names resulted in a change to the web-exposed interface. Instead of importance it will be using fetchpriority for the HTML attributes and priority for the fetch JavaScript API.

The spec has been updated with the new attribute names (that was the only change, the actual values for the attribute are the same as is the behavior).