[meta] Add fetchpriority=high on certain images/oembeds

Fetch priority only affects the order that image assets are loaded in relative to other images.

Preload directives on the other hand reorder asset downloads across all content types.

While fetch priority is likely easier to implement, I feel that preloads are a more effective means to ensure LCP asset downloads are prioritized as high as possible in the waterfall. To this end I've crafted Responsive Image Preload. It can be a bit unwieldy to use, but it has effectively lowered our LCP by approximately 18%. Perhaps some inspiration can be drawn from it?

Fetch priority only affects the order that image assets are loaded in relative to other images.

This is not quite correct. All browsers delay images (and other lower priority resources) while they work on more critical render-blocking assets (e.g. CSS, and sync JS). Adding fetchpriority="high" to an important image (typically the LCP image) allows them to be fetched immediately without this delay. This has the larger impact on the load time of important images, than being prioritised above other images.

I feel that preloads are a more effective means to ensure LCP asset downloads are prioritized as high as possible in the waterfall

This is a common misunderstanding, and requires a bit more nuance. Even preloaded images are still "held back". However, for late discovered images, fetchpriority can be used with preload, to again get that preloaded image fetched immediately:

<link rel="preload" href="lcp-image.jpg" as="image" fetchpriority="high">

Personally, I advise not to overuse preload (I've see it fall out of sync with the main image if one is changed but not the other!), but that may be less of a concern with an automated solution like yours.

Also, to be fair to your argument, preload does have the added advantage of the browser that do not support fetchpriority discovering that before the other images, so giving it a slight bump even without bumping it fully into that early load phase. fetchpriority is currently only supported on Chromium-based browsers, but FireFox have said they are planning on looking into this early next year, and there is no downside to this attribute for non-supporting browsers (though potentially there is an argument to supplement with preload for those browsers, subject the warning I gave above).

I note that the screenshots in your Responsive Image Preload seem to contradict what I'm saying here, so would be curious to see that test page to see why that is. Once an origin is down to 1-2 critical resources it will start to fetch the lower-priority resources (including images), so it could be that example only has one or two render blocking resources on the same origin as the image?

Fetch priority only affects the order that image assets are loaded in relative to other images.

This is not quite correct.

I based that statement on a mix of personal testing on current tech as well as https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchP...

The fetchPriority property of the HTMLImageElement interface represents a hint given to the browser on how it should prioritize the fetch of the image relative to other images.

(emphasis mine)

as well as the priority hints working draft at https://wicg.github.io/priority-hints/

The fetchpriority attribute will have three states:
high - The developer considers the resource as being important relative to other resources of the same type.

Of course, performance tuning is an extremely difficult thing to get correct generically. Every site will likely differ for optimal configuration. In the wild, I've seen things happen like non-render-blocking webfonts prioritized higher than images with a fetch priority of high set. -- my memory fails me! We were actually experimenting with font-display instead of fetchpriority in our original testing. The order in which these assets appear in the document response seems to somewhat influence how they're queued for download, though I haven't been able to detect a 100% reliable pattern.

It also wouldn't shock me if the implementations evolve over time as more real-world stats become available to vendors.

I just want to re-clarify that I'm not against the use of fetchpriority in core -- as an optional thing to set up on image formatters, it makes a lot of sense. In our particular case, using fetchpriority still had the image stuck behind up to 11 webfonts.

Interesting comments on the docs! Will raise that with a few people here at Google to see if we can improve that. Thanks for pointing it out.

BTW, the working draft does have this bit further down:

Queueing

A user agent might choose to queue up certain low-priority requests until higher-priority requests are sent out or finished in order to reduce bandwidth contention. Implementations are encouraged to use Priority Hints to determine whether a given request is a candidate for such queueing so that more important resources are fetched and used earlier, in order to improve the user’s experience.

but easily missed given the earlier wording you pointed out.

Very basic, but high priority could be attached to the logo in themes, which is pretty much guaranteed to be the first image to load (especially if the theme adds the attribute).

I'm looking into doing this on my client site's hero image (which is a media image rendered with a custom view mode).

Adding a note that this is more difficult than it should be. I'd love a setting (maybe grouped with the new Lazy load setting) where I could toggle this on and off.

Turning this into a meta issue, since there are two issues for implementation now.