Responsive LCP image penalized for lazy-loading by lcp-lazy-loaded audit

### FAQ

- [X] Yes, my issue is not about [variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) or [throttling](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md).
- [X] Yes, my issue is not about a specific accessibility audit (file with [axe-core](https://github.com/dequelabs/axe-core) instead).
- [X] Yes, my issue is not answered by [other FAQs](https://github.com/GoogleChrome/lighthouse#faq).

### URL

https://westonruter.github.io/comparing-lcp-images-with-lazy-loading-and-fetchpriority-high/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=lazy` to the images:

```html


```

Nevertheless, since these are LCP images for their respective viewport sizes, they also must be loaded with `fetchpriority=high` which can be achieved with preload links that include media queries:

```html

```

Nevertheless, the lcp-lazy-loaded audit is failing for [such a page](https://westonruter.github.io/comparing-lcp-images-with-lazy-loading-and-fetchpriority-high/lazy-loaded-lcp-image-with-fetchpriority-high-preload-link.html) ([PSI](https://pagespeed.web.dev/analysis/https-comparing-lcp-images-with-lazy-loading-and-fetchpriority-high-glitch-me-lazy-loaded-lcp-image-with-fetchpriority-high-preload-link-html/zivl3ud2rx?form_factor=mobile)):

> 

This is in spite of the fact that such images load comparably fast to `img` tags with `fetchpriority=high`:

Test Case
Broadband
Fast 4G




Plain LCP image
323.4 ms
742.3 ms



Lazy-loaded LCP image

317.6 ms
741.3 ms



Lazy-loaded LCP image with fetchpriority=high attribute

318.7 ms
742.1 ms



LCP image with fetchpriority=high attribute

288.3 ms
542.7 ms



LCP image with fetchpriority=high preload link

289.0 ms
545.1 ms



Lazy-loaded LCP image with fetchpriority=high preload link

288.1 ms
542.7 ms

For more info, see the [GitHub repo](https://westonruter.github.io/comparing-lcp-images-with-lazy-loading-and-fetchpriority-high/).

### 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 `src` and `srcset` it should also check if there is a preload link with `fetchpriority=high` which has the corresponding `href` and `imagesrcset` attribute values. If so, then `wasLazyLoaded` should be considered `false`.

### 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_

Start with core/audits/lcp-lazy-loaded.js at the referenced logic around line 88, then reproduce the audit against the linked responsive-image page. Check how the LCP image’s src and srcset can be matched to a high-priority preload’s href and imagesrcset. Done means the audit no longer flags this case while preserving its existing behavior for genuinely lazy-loaded LCP images.

Written by the indexing model from the issue text.