One in six sites lazy-loads the image it is graded on

On 76% of mobile pages, the Largest Contentful Paint element is an image. Between 16 and 17% of pages apply lazy loading to that exact image. So roughly one in six sites has instructed the browser to deprioritise the single asset its speed score is calculated from.

This is not a fringe mistake. It is the most common self-inflicted performance problem on the web, and it is usually introduced by a well-meaning developer following advice that was correct for every other image on the page.

Why it happens

Lazy loading is good advice. Adding the lazy loading attribute to images below the fold stops the browser downloading things nobody scrolls to, and on a long page that saves real bandwidth.

The problem is application. Someone adds it globally, in a CMS image component or a template partial, and it lands on the hero along with everything else. In WordPress it is worse, because lazy loading is applied automatically, and themes vary in whether they correctly exclude the first image.

Nobody notices, because the page still works. The hero appears. It just appears later than it should, and the delay is invisible on a fast office connection with a warm cache.

The mechanism, because the mechanism is the argument

Browsers run a preload scanner. While the main HTML parser is blocked on a stylesheet or a script, the scanner races ahead through the raw markup, finds resource URLs, and starts fetching them early. It is the single biggest reason modern pages are not slower than they are.

An image marked for lazy loading is deliberately excluded from that early fetch. The browser waits until layout has been calculated and it knows where the image sits relative to the viewport, and only then requests it. On a hero image that adds a full round trip after layout, on a connection where a round trip to a Sydney edge is tens of milliseconds and to a US origin is over two hundred.

You have taken your most important asset out of the fast path and put it in the slow one.

The three fixes, in order of impact

Remove the lazy loading attribute from the LCP image. Not from all images. From the one that is the LCP element on that template. Check each template separately, because a blog article, a service page and the homepage often have different LCP elements.

Add the high fetch priority hint to it. This is the underused one. Only around 17% of pages set a fetch priority at all. Removing lazy loading gets the image back into the preload scanner queue, but it still queues behind other resources the browser guesses are more urgent. Marking it high priority tells the browser this specific image outranks them. On a page with a hero image and a dozen other assets, that reordering alone is often several hundred milliseconds.

Stop hiding it from the scanner. A CSS background image is invisible to the preload scanner, because the scanner reads HTML, not stylesheets. Same for an image inserted by JavaScript, or one behind a carousel library that builds slides on load. If your hero is any of those, no amount of priority hinting helps, because the browser does not know the image exists until much later. Put a real image element in the markup.

The responsive image trap sitting underneath

Once the image is loading early with high priority, check what size is actually downloading.

Responsive images use a candidate set to list files and a sizes value to tell the browser how wide the image will render. Get the sizes value wrong and the browser picks the wrong candidate, usually a much larger one, and you have made the fast path slow again by downloading a 2400px file into a 390px viewport.

The common error is declaring full viewport width on an image that renders in a constrained column, or leaving the default when the image is half width on desktop. Check it in DevTools: the Network panel shows which candidate was chosen, and the Elements panel shows the resolved source on the image.

How to verify in ten minutes

Open PageSpeed Insights on your five highest traffic pages. The LCP element is named directly in the diagnostics. For each one:

1. 1.View source and find that element. Confirm there is no lazy loading attribute on it.
2. 2.Confirm the high fetch priority hint is present.
3. 3.Confirm it is a real image element in the served HTML, not a background image or something a script inserts.
4. 4.Check LCP resource load delay in the Chrome DevTools performance panel. If it is more than a couple of hundred milliseconds, the browser found the image late, and one of the three points above is the reason.

Then check whether your CMS is going to undo it. If lazy loading is applied by a plugin or a shared component, fixing the template by hand means the next content editor who reuploads a hero puts the problem straight back. Fix it at the component level, with an explicit priority flag on the hero slot.

The browser will do almost all of this work for you, as long as you stop telling it not to.