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.
Umair Khan •

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.

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.



Leave a Reply