Image Prioritizer fails to preload LCP images for picture elements

[westonruter]

The Image Prioritizer plugin adds a preload link tag with fetchpriority=high for the URL contained in the src attribute of the img. When the Modern Image Formats plugin is active and the "Use <picture> element" option is enabled, then the img is wrapped in picture with other source elements for WebP and AVIF image formats. Because of this, the preload link will usually be wrong because the actual URL being used for the LCP image will be the WebP or AVIF image, not the JPEG fallback.

For example, a page containing this LCP element:

<picture class="wp-picture-13">
  <source type="image/webp" srcset="http://localhost:8888/wp-content/uploads/2024/06/bison1-1024x668-jpg.webp 1024w, http://localhost:8888/wp-content/uploads/2024/06/bison1-300x196-jpg.webp 300w, http://localhost:8888/wp-content/uploads/2024/06/bison1-768x501-jpg.webp 768w" sizes="(max-width: 1024px) 100vw, 1024px">
  <source type="image/jpeg" srcset="http://localhost:8888/wp-content/uploads/2024/06/bison1-1024x668.jpg 1024w, http://localhost:8888/wp-content/uploads/2024/06/bison1-300x196.jpg 300w, http://localhost:8888/wp-content/uploads/2024/06/bison1-768x501.jpg 768w" sizes="(max-width: 1024px) 100vw, 1024px">
  <img fetchpriority="high" width="1024" height="668" src="http://localhost:8888/wp-content/uploads/2024/06/bison1.jpg" class="attachment-1024x668 size-1024x668 not-transparent" alt="" data-has-transparency="false" data-dominant-color="8c7d58" style="width:100%;height:65.23%;max-width:1024px;--dominant-color: #8c7d58;">
</picture>

Is getting this preload link:

<link data-od-added-tag="" rel="preload" fetchpriority="high" as="image" href="http://localhost:8888/wp-content/uploads/2024/06/bison1.jpg" media="screen">

In this specific example, the LCP element is the same across all breakpoints, so the fetchpriority=high on the img itself is sufficient and the preload link is not required. Nevertheless, if the LCP element is not the same across all breakpoints, the fetchpriority=high attribute cannot be added to the img or else it will get loaded with high priority for some breakpoints for which it is not the LCP image. This basically uncovers a performance problem with using <picture> as it cannot be reliably loaded with high priority to improve LCP. This is essentially a known issue per https://github.com/GoogleChrome/web.dev/issues/6150.

For Image Prioritizer, the preload link needs to be omitted when the related LCP element is a picture element. It can still add fetchpriority=high to the img as it does now when all breakpoints share it as the LCP element.

Cheers to @aaemnnosttv for talking this through with me at WCEU.

[westonruter]

As came up in the Core Performance chat today, will a browser skip preloading a link that has a type for an image format that it doesn't support? If so, then we could add the preload link for AVIF or WebP. But we would still have to omit the preload link for the JPEG fallback, since then even browsers browsers that support AVIF/WebP would be fetching the JPEG as well even though only the former would be used.

[westonruter]

It looks like Chrome at least does exclude preloading image formats that it doesn't support: https://jpegxl-preload-link.glitch.me/

This is in fact part of the HTML spec:

4.2.4.2 Processing the type attribute

If the type attribute is present, then the user agent must assume that the resource is of the given type (even if that is not a valid MIME type string, e.g. the empty string). If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. If the UA does not support the given MIME type for the given link relationship, then the UA should not fetch and process the linked resource; if the UA does support the given MIME type for the given link relationship, then the UA should fetch and process the linked resource at the appropriate time as specified for the external resource link's particular type. If the attribute is omitted, and the external resource link type does not have a default type defined, but the user agent would fetch and process the linked resource if the type was known and supported, then the user agent should fetch and process the linked resource under the assumption that it will be supported.

So it looks like we can indeed add preload links for picture elements, but only for the AVIF/WebP source and not for the fallback JPEG. If the source also has a media attribute, then this will need to be merged with whatever media is computed for the LCP element viewport group.

[westonruter]

If a picture element is used not merely as a way to serve a modern format but instead has multiple source elements for art-directed images, then there will need to be separate preload links for each one, again replicating the media attribute from the source element to the link element (and merging with the viewport group media query).

[westonruter]

See also https://web.dev/articles/preload-responsive-images#picture