Bug 247291 – Add support for Fetch Priority

• Component: DOM
• Status: RESOLVED FIXED

[Patrick Meenan]

The Priority Hints spec is in the process of being merged into the fetch and HTML specs and allows for site developers to hint at the relative fetch priority for various resources.

The main changes are:
* Adds a "priority" to fetch's Request and RequestInit classes that uses a string enum of "auto", "high" or "low"
* Adds a "fetchPriority" attribute to the IMG, PICTURE, SCRIPT, LINK and IFRAME html elements with the same enum values

Existing spec: https://wicg.github.io/priority-hints/

This was shipped in Chromium 103 and Mozilla is working on an implementation so it is now in the process of being moved into the HTML and fetch specs.

The main use case developers are currently using it for is to tag "important" images on their pages so that they load sooner than the would naturally.  Chrome usage from the field can be seen here: https://chromestatus.com/metrics/feature/timeline/popularity/2738

[Radar WebKit Bug Importer]

<rdar://problem/102058327>

[Rob Buis]

Created attachment 464982 [details]
Patch

[Rob Buis]

Pull request: https://github.com/WebKit/WebKit/pull/10084

[Patrick Meenan]

FYI, there is discussion on the HTML spec PR about removing it from iFrame and leaving it as a hint for same-document subresources and exploring iFrame scheduling separately.

https://github.com/whatwg/html/pull/8470#discussion_r1106835444

I imagine that WebKit has a lot of similar details to Chrome for why prioritizing the fetch of the iFrame navigation resource might be ineffective and not do what the site devs are trying to achieve (prioritizing across frame boundaries at the document and network level probably won't do anything in Chrome for example).

Script, IMG and Link tag fetchpriority attributes (as well as fetch RequestInit) all still have very clear use cases though.

[Rob Buis]

(In reply to Patrick Meenan from comment #4)
> FYI, there is discussion on the HTML spec PR about removing it from iFrame
> and leaving it as a hint for same-document subresources and exploring iFrame
> scheduling separately.
> 
> https://github.com/whatwg/html/pull/8470#discussion_r1106835444
> 
> I imagine that WebKit has a lot of similar details to Chrome for why
> prioritizing the fetch of the iFrame navigation resource might be
> ineffective and not do what the site devs are trying to achieve
> (prioritizing across frame boundaries at the document and network level
> probably won't do anything in Chrome for example).
> 
> Script, IMG and Link tag fetchpriority attributes (as well as fetch
> RequestInit) all still have very clear use cases though.

Thanks for the link! As it happens I did not start on making iframe + priority hints work because, I guess like others found out, it would be a lot more changes/plumbing to make that work. I would be fine too of course removing the idl for it.

[EWS]

Committed 260666@main (adf13d454519): <https://commits.webkit.org/260666@main>

Reviewed commits have been landed. Closing PR #10084 and removing active labels.

[Rob Buis]

Still needs implementation.

[Chris Dumez]

Comment on attachment 464982 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=464982&action=review

> Source/WebCore/Modules/fetch/RequestPriority.idl:28
> +  "high"

Someone pointed out on Slack that this is missing commas between the values, please follow-up and fix.

[Rob Buis]

I implemented the feature, but don't have the expertise to work on bug 254028, so I am removing myself as assignee.

[Barry Pollard]

FYI, in Chrome we're trying to consolidate on "Fetch Priority" and avoid using "Priority Hints" going forward to reduce developer confusion.

More info:
- https://twitter.com/tunetheweb/status/1648399924424237058?s=20
- https://web.dev/fetch-priority/#history

[Anne van Kesteren]

Closing this as fixed as per bug 255008. We'll continue to track the inspector work in bug 254028.