LCP Image Lazy Loaded in WordPress: Fix With fetchpriority and Preload

A lazy-loaded hero image can delay your Largest Contentful Paint. Learn why WordPress lazy-loads it, and how to fix it with fetchpriority and a correct preload.

LCP image lazy loaded in WordPress and why it happens, explained by ProSpeedGuy

Is your store paying for requests it doesn’t need?

A free audit checks this exact request, plus LCP, INP, and CLS, on your live store.

LCP image lazy loaded WordPress: why is my hero image lazy loaded?

LCP image lazy loaded WordPress means the browser holds back the very image that defines Largest Contentful Paint. Lazy loading is useful for images below the fold, because it lets the browser skip them until they are needed. A hero image is the opposite case: it is visible at once, so delaying it delays the moment the page looks complete.

The cause is rarely one setting. A theme can add loading=”lazy” to every image it outputs. A page builder can do the same for its image widgets, especially when a global performance option is switched on. An optimization plugin can rewrite image tags and add lazy loading after the theme has rendered them. In each case, the hero is treated like any other image, even though it is the first thing a visitor sees.

WordPress core adds to this picture. The WordPress developer reference describes core functions that add a loading attribute to image and iframe tags, and a loading-optimization function that can return lazy loading, fetchpriority, and decoding attributes for an element. That logic is meant to treat early media differently, but it does not guarantee that every hero escapes lazy loading. A hero delivered through a theme header, a builder section, a cover block, or a custom template may not be handled as the early content image you expect, and a plugin or builder setting can still add lazy loading afterwards. Check the rendered page, not just the setting you think you changed.

Confirm the problem before you fix it. Right-click the hero, choose Inspect, and look at the image tag itself. If it carries loading=”lazy”, you have found it. Then run PageSpeed Insights and look at the Largest Contentful Paint element it names. If the element it names is that same image, the lazy attribute is not a harmless detail. Check mobile and desktop separately, because a site can use a different hero, crop, or responsive variant on each.

PageSpeed Insights does not need to give you a new score for this to matter. Its LCP element diagnostic tells you which element the browser measured. If that element is an image that is being deferred, fixing the loading attribute is the work, not chasing a different metric. For the wider picture, start with the broader WordPress Core Web Vitals guide, which puts LCP alongside the other metrics that share the same page.

How to set fetchpriority

Set fetchpriority=”high” and loading=”eager” on the LCP image only. The fetchpriority attribute tells the browser to prioritise that resource. The loading=”eager” value removes the lazy deferral. Used together on the right image, they tell the browser plainly: this image matters now. Used on every image, they tell the browser nothing useful, because everything cannot be high priority at once.

  • Identify the exact LCP image first, including the responsive variant the browser actually uses on mobile and on desktop. Fixing a different crop will not fix the measured element.
  • Find that image in your theme, builder, or image settings. If your tool has a fetchpriority or priority control for that image, use it there.
  • If there is no control, edit the image markup for that image only. The result should look like this: <img src=”hero-image.jpg” alt=”Your hero image description” width=”1200″ height=”800″ loading=”eager” fetchpriority=”high”>.
  • Re-inspect the live page. The LCP image tag should no longer carry loading=”lazy”, and it should carry fetchpriority=”high”.
  • Clear any page cache after the change, then retest. A cached page can keep serving the old lazy tag long after you have fixed the source.

Do not set fetchpriority=”high” on a logo, a secondary image, or anything below the fold. That spreads the priority signal and can push the LCP image behind work that does not matter yet. One high-priority image per page is the right mental model for a hero fix. LCP is only one metric, so if interactions also feel slow after this fix, read the guide to fixing slow interactions in WordPress next, rather than adding more priority flags.

Fix LCP with fetchpriority and preload in WordPress

How to preload the LCP image

Preloading helps when the browser discovers the LCP image too late. That happens when the image is set as a background, buried in builder markup, or referenced only after other resources. A preload link in the head tells the browser to fetch the image early, before the parser reaches the image itself. It does not replace fetchpriority: preload improves discovery, while fetchpriority improves priority. For a hero that is already early in the markup, fetchpriority alone may be enough. For a hero that is discovered late, preload is the extra step that makes the difference.

A correct preload for a straightforward image looks like this: <link rel=”preload” as=”image” href=”hero-image.jpg” fetchpriority=”high”>. If the image uses responsive images, the preload must match the variant the browser will actually choose, using imagesrcset and imagesizes, or the browser may download a different file and the preload will be wasted. Add the preload to the head of the page through your theme or a trusted optimization plugin, not as text inside the post content, and preload only the one LCP image.

Three mistakes undo this work more often than any other. First, preloading an image that is not the LCP element, such as a logo or a different crop, spends an early fetch on the wrong file. Second, lazy loading and preloading the same image, or combining loading=”lazy” with fetchpriority=”high” on the same element, sends contradictory instructions. WordPress developer documentation warns that no element should carry both loading=”lazy” and fetchpriority=”high”. Third, changing width and height carelessly, or omitting them, can shift layout as the image loads and create a Cumulative Layout Shift problem while you are trying to fix LCP. Keep the width and height that match the displayed aspect ratio, and test the responsive sizes rather than guessing them.

After the fix, retest with the same tool you used to find the problem, and check both mobile and desktop. If the LCP element changes after your fix, you have learned something useful: the next element in line may need attention, but do not preload that one as well unless it is genuinely the new LCP image on that page. Avoid chasing rumours about metric changes instead of fixing the element in front of you; the Core Web Vitals myth-bust is a useful check before you rebuild a working setup.

When you need to delay non-essential scripts rather than images, the guide to delaying JavaScript execution in WordPress covers that separately, and the best WordPress speed test tools and the best WordPress cache plugins review can help you measure and cache the result consistently.

Common Questions

Frequently Asked Questions

Clear, honest answers about lazy-loaded LCP images, fetchpriority, and preload.

Yes, when the image is discovered late. Preload helps the browser find the image early, and fetchpriority raises its priority once found. They do different jobs, so they complement each other on the LCP image. Do not use either one on every image, and never combine them with loading=”lazy” on the same element.

You cannot add fetchpriority directly to a background image, because there is no image element to carry the attribute. You can preload the background image URL, but the cleaner fix is usually to use a real image element for the hero, so the browser can prioritise it and report it as the LCP element.

Check three things before you change anything else: whether a cached page is still serving the old markup, whether the mobile variant differs from the desktop one you fixed, and whether the LCP element itself has changed now that the hero loads earlier.

No. Lazy loading is the right default for images below the fold, because it keeps the browser from downloading work a visitor may never see. Remove it only for the visible LCP image, and leave the rest lazy loaded.

No. Preload helps the browser discover the image earlier, and fetchpriority helps the browser prioritise it once it is known. If the image is already early in the markup, fetchpriority alone may be enough. If it is discovered late, use both on the LCP image only.

Use PageSpeed Insights and read the Largest Contentful Paint element it names. Compare that URL with the image tags on your page, then fix that exact image and responsive variant on the device that was measured. Guessing at a different hero will not fix the reported element.

Keep reading

  • PageSpeed lab score looking good beside failing real-visitor field data, the PageSpeed good Core Web Vitals fail pattern

    PageSpeed Looks Good but Core Web Vitals Fail? Lab vs Field Data Explained

    A good lab score does not always mean a passing Core Web…
    November 9, 2026
  • Slow loading Google Fonts typography on a WordPress page, where Google Fonts slow WordPress text rendering

    Are Google Fonts Slowing Down WordPress? How to Fix Slow, Shifting Text

    Text that appears late, flashes, or jumps after loading can make a…
    November 5, 2026
  • WordPress site slow on mobile phone compared with fast desktop

    WordPress Slow on Mobile Only? How to Find the Mobile-Only Cause

    Your site feels fine on a laptop but slow on a phone….
    November 2, 2026

Leave a Reply

Your email address will not be published. Required fields are marked *