LCP request discovery" audit incorrectly reports "fetchpriority=high" should be applied.

[andyj2022]

FAQ

• [x] Yes, my issue is not about variability or throttling.
• [x] Yes, my issue is not about a specific accessibility audit (file with axe-core instead).
• [x] Yes, my issue is not answered by other FAQs.

URL

https:/example.com/anyweb

What happened?

Hello Lighthouse Team,

I'm running a Lighthouse audit and encountering an incorrect result in the "LCP request discovery" section.

Actual Behavior: The audit fails the check "fetchpriority=high should be applied", as shown in the attached screenshot.

Expected Behavior: This check should pass, as the LCP element identified by Lighthouse already has the fetchpriority="high" attribute.

Evidence: Here is the HTML snippet for the LCP element, taken directly from the Lighthouse report:

HTML

<img alt="" fetchpriority="high" height="540" loading="eager" src="[...]" width="960">

As you can see, the fetchpriority="high" attribute is clearly present on the tag.

I suspect the audit might be incorrectly parsing the attribute, perhaps because the value is quoted ("high"). This is valid HTML, so the audit should be able to recognize it.

Thank you for looking into this.

What did you expect?

I expect the "fetchpriority=high" should be applied check to pass.

The Lighthouse report itself shows that the LCP element already has the fetchpriority="high" attribute, so this audit should show a green checkmark, not a red error.

What have you tried?

No response

How were you running Lighthouse?

Chrome DevTools, PageSpeed Insights

Lighthouse Version

13.0.1

Chrome Version

No response

Node Version

No response

OS

No response

Relevant log output

[connorjclark]

I suspect the audit might be incorrectly parsing the attribute, perhaps because the value is quoted ("high"). This is valid HTML, so the audit should be able to recognize it.

that can't be the issue.

this sounds a bit like https://github.com/GoogleChrome/lighthouse/issues/16650

Can you provide a real URL so I can repro?

[andyj2022]

Thanks. That was exactly it: the header wasn't sending the fetchpriority=high, even though it was in the HTML.

I'm not closing the issue: you can close it if you consider that behavior correct.

[iceberg53]

I'm facing a similar issue too using PSI even though sometimes it gets it right. For example, it failed here : https://pagespeed.web.dev/analysis/https-www-freetiers-com-blog-aws-api-gateway-vs-azure-logic-apps-comparison/i8xjrby1x8?form_factor=mobile while it got it right there : https://pagespeed.web.dev/analysis/https-www-freetiers-com-blog-aws-api-gateway-vs-azure-logic-apps-comparison/0iy09762fi?form_factor=mobile .

By the way, I'm also preloading the image which explains why I didn't get that issue on other pages where there was no preloading in place.

I added the fetchpriority attribute to the preload link and the issue disappeared. Thanks.