Open westonruter opened 4 weeks ago
adamraine
commented
4 weeks ago Is there any reason you can't use <picture> instead? Even though the image loading doesn't appear to be affected by loading=lazy in this case, I don't see why you need to use it other than to select a specific img src which is a feature that is better provided by <picture> IMO.
westonruter
commented
4 weeks ago Using a picture element would be an alternative, yes, but it wouldn't always be an option. Not all platforms support generating picture elements, and the different image in question may be located in separate DOM trees. Consider a page which has two separate headers, one for mobile and one for desktop, within each there is a separate img specific to mobile and desktop respectively. A picture element wouldn't work in this case.
My interest here is specifically in the context of developing optimizations on top of WordPress Core. I'm working to take the existing markup generated by the theme and prioritize the loading of the LCP image based on the current viewport. WordPress doesn't support picture yet. My concern is that if the optimization adds loading=lazy to the LCP image while also adds responsive fetchpriority=high preload links, Lighthouse will flag this as an error even though in reality the performance is improved. So a user testing their site in Lighthouse will think the optimization (https://github.com/WordPress/performance/issues/1270) is making things worse.
adamraine
commented
3 weeks ago I think you could still get picture to work by using two picture elements and loading a "null" data URI image for the viewport size that isn't applicable. That being said this approach is equally hacky if not more hacky compared to the lazy loading approach and you also mentioned how picture may not be available in all cases.
I think we will adopt your suggestion of allowing images with loading=lazy if they have a link preload tag with fetchpriority=high
FAQ
URL
https://comparing-lcp-images-with-lazy-loading-and-fetchpriority-high.glitch.me/lazy-loaded-lcp-image-with-fetchpriority-high-preload-link.html
What happened?
Consider a page which shows a different image depending on whether it is a desktop or mobile device. In order to prevent both images from being loaded on both device form factors, it is necessary to add
loading=lazyto the images:Nevertheless, since these are LCP images for their respective viewport sizes, they also must be loaded with
fetchpriority=highwhich can be achieved with preload links that include media queries:Nevertheless, the lcp-lazy-loaded audit is failing for such a page (PSI):
This is in spite of the fact that such images load comparably fast to
imgtags withfetchpriority=high:The LCP-TTFB metric comes from the benchmark-web-vitals command in the GoogleChromeLabs/wpp-analysis repo. It reflects the LCP time subtracting the TTFB. The value is the median over 25 requests using the following command:
For more info, see the Glitch.
What did you expect?
The lcp-lazy-loaded should not have failed.
What have you tried?
I suggest that the following code in the audit be modified:
https://github.com/GoogleChrome/lighthouse/blob/a1d424eef4c8ab1d0ef6c7c71dd7e212316e9ba9/core/audits/lcp-lazy-loaded.js#L88
Given the LCP image's
srcandsrcsetit should also check if there is a preload link withfetchpriority=highwhich has the correspondinghrefandimagesrcsetattribute values. If so, thenwasLazyLoadedshould be consideredfalse.How were you running Lighthouse?
PageSpeed Insights, Chrome DevTools
Lighthouse Version
12.0.0
Chrome Version
No response
Node Version
No response
OS
No response
Relevant log output
No response