LCP image is lazy-loaded or not prioritised

SeverityMedium

ScopeWhole site

EffortSmall

Verified byLighthouse

Rule keylcp_image_not_prioritised

Short answer

On this page LCP is slow and the Largest Contentful Paint element is an image that the browser loads late: it has loading="lazy", it has no fetchpriority="high" hint, or it is not discoverable in the initial HTML (added by JavaScript or set as a CSS background). Remove lazy-loading from that image, add fetchpriority="high", and make sure the <img> (or a <link rel="preload" as="image">) is in the HTML the server sends.

Why it matters

LCP is one of the three Core Web Vitals. When the largest image in the first screen is lazy-loaded, the browser waits until layout to request it; when it is discovered late, every other request goes first. Both add hundreds of milliseconds on mobile. These are among the cheapest LCP fixes because they change attributes, not design.

How Glimana detects it

Glimana uses the Lighthouse (PageSpeed) mobile runs of the last 14 days — weekly for the home page and the ten most-clicked pages. The rule only looks at pages where LCP is slow: the CrUX field p75 over 2.5 s for the page (or for the whole site when the page has no field data), or, without any field data, a lab LCP over 4 s. For those pages it reads the LCP element Lighthouse reports. loading="lazy" on it is reported when it is in the element's HTML; a missing priority hint and "not discoverable in the initial HTML" are reported only when Lighthouse's own LCP discovery check measured them. The evidence shows the element, the problems found, and the LCP value with its source (field or lab).

How to fix it

Find the affected pages in Glimana. Open Issues › LCP image is lazy-loaded or not prioritised. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
Apply the fix on your platform.

Apply the parts named in the evidence to the LCP image only (usually the hero or the first product image):
```
<img src="/hero.webp" width="1200" height="630" alt="…" fetchpriority="high">
```
- Lazy: remove loading="lazy" (or set loading="eager"). Keep lazy-loading for images further down the page.
- No priority hint: add fetchpriority="high". Use it on one or two images per page at most.
- Not in the initial HTML: render the <img> on the server. If the image must stay a CSS background or be injected by script, add <link rel="preload" as="image" href="…" fetchpriority="high"> in the <head>.
WordPressShopifyCustom code

Since WordPress 6.3, core adds fetchpriority="high" to the image it detects as the likely LCP element and does not lazy-load the first images in the content. If the evidence still shows lazy, a performance or lazy-load plugin (for example in a cache plugin's media settings) is adding it back: exclude the hero image or the first image from lazy-loading in that plugin. For a hero set as a background in the theme or page builder, switch it to an image block, or add the preload in the theme's <head>.

In the section that renders the first image, output it with image_tag and pass loading: 'eager' and fetchpriority: 'high' for the first section on the page (themes such as Dawn use section.index to decide this). Make sure an app is not lazy-loading every image. Avoid slideshows whose first slide is injected by JavaScript.

Mark the first-viewport image in the component that renders it: no loading="lazy", add fetchpriority="high", set width and height. In frameworks with an image component, use its priority option (for example priority in Next.js <Image>). Server-render the element so it is in the first HTML response.
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with curl -s https://your-domain/page | grep -i '<title\|canonical\|robots' that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached.
Verify in Glimana. Open the task under Tasks and click Mark as done. The rule reads the latest Lighthouse run of the page, and runs happen weekly (Saturday), so the result can take up to a week. The task closes when the LCP image is no longer lazy-loaded, has a priority hint and is discoverable in the initial HTML. If the check still fails, the task returns to New with a note. Field LCP on the Speed page catches up over the following 28 days.

Test one URL now

The free speed tool runs PageSpeed on mobile for a single URL: scores, Core Web Vitals and the 10 most expensive audits. No account needed.

How the fix is verified

The next weekly Lighthouse run re-reads the LCP element; the task closes when none of the reported problems remains. Field LCP (CrUX) improves gradually over 28 days.

FAQ

Should I add fetchpriority="high" to every image?

No. Priority is relative: if everything is high, nothing is. Use it for the LCP image, and at most one other critical image.

Lighthouse says LCP is fine now. Why is the task still open?

The rule needs the next Lighthouse run to see the change, and only fires while LCP is slow. If field LCP is still above 2.5 s, other causes remain; see Poor LCP in field data.