Lazy Loading in WordPress: What It Does and When It Hurts
WordPress has shipped lazy loading on images by default for a few years now. Most site owners have never touched the setting, which is fine, until it starts costing them. The browser defers images that are off-screen at load time, which sounds sensible on paper. The catch is that WordPress does not always know which images are truly off-screen, and when it gets that wrong, your Largest Contentful Paint score takes the hit before a single visitor has scrolled anywhere.
On this page
What Lazy Loading Does in the Browser
The loading="lazy" attribute is a single HTML instruction that tells the browser to hold off fetching an image until the user scrolls close to it.
Without it, the browser downloads every image on the page the moment it starts parsing the HTML, regardless of whether those images are visible or buried three scrolls down. Add loading="lazy" to an <img> tag and the browser defers the request until the image enters, or nearly enters, the viewport. The exact trigger distance varies by browser, but Chromium-based browsers typically begin fetching once an image is within roughly 1,200 pixels of the visible area on a fast connection, pulling that threshold closer on a slower one. The practical effect is that a page with thirty product images may only request six or seven on initial load, with the rest following as the visitor scrolls. That reduces the volume of bytes the browser has to handle before it can paint the page and respond to interaction.
The browser makes this decision independently for each image. It checks the loading attribute, considers the image’s position relative to the viewport, and factors in current network conditions. It does not consult the CMS, the theme, or any plugin. Whatever WordPress or a page builder outputs in the HTML is what the browser acts on, which is why understanding what ends up in the markup matters far more than assuming a setting has been applied correctly.
Why WordPress Gets It Wrong by Default
WordPress added native lazy loading in version 5.5, and on paper it looked like a sensible move. Deferring off-screen images cuts unnecessary requests and reduces initial page weight. That logic holds for images buried halfway down a long page. The problem is that WordPress applies the loading="lazy" attribute broadly, without always accounting for which image is sitting at the very top.
When your theme uses a full-width hero image or a featured image banner, that asset is almost certainly the Largest Contentful Paint element. Telling the browser to delay loading it is the same as telling your fastest runner to wait at the start line. Google measures LCP as one of the Core Web Vitals signals that directly influence search rankings, so a lazily loaded hero can drag scores down on an otherwise well-built site.
Most themes compound the issue because the featured image is baked into the template at the top of every post and page, making it the first large element the browser encounters. Without a manual override, WordPress will flag it lazy regardless. The fix is not complicated, but it does require knowing where to look in the markup and being deliberate about which images get loading="eager" instead.
Which Images Should Never Be Lazy Loaded
Above-the-fold HTML images
Hero images, above-the-fold banners, and your logo are the clearest cases. These elements are visible the moment a page loads, so telling the browser to defer them is counterproductive. The browser fetches lazy-loaded assets only after the initial render, which means a visitor stares at an empty space while the image catches up. On a hero section that takes up most of the viewport, that gap is exactly what Google’s Largest Contentful Paint metric measures. Lazy loading those images does not save bandwidth; it just shifts the cost onto your LCP score.
CSS background images
CSS background images sit in a different category entirely, and they catch a lot of people out. When a page builder sets an image as a CSS background rather than a standard HTML img element, the browser’s native lazy loading attribute has no effect on it at all. The image loads regardless, but without any of the priority signals that help it load fast.
If that background is your main banner, you want it discovered and fetched as early as possible, which means preloading it explicitly, not deferring it. The same logic applies to any thumbnail used in an Open Graph tag or structured data block, since those assets feed previews that also depend on being present. Get the categorisation wrong and you either delay what should be instant or preload what nobody sees above the fold.
How to Override Lazy Loading on Specific Images
The most direct fix is adding loading="eager" to any image that needs to load immediately. In the block editor, select the image block, open the Advanced panel in the right-hand sidebar, and paste loading="eager" into the Additional CSS class field, then handle it in your theme’s CSS or use a block attribute filter. A cleaner route in block themes is editing the HTML directly via the three-dot menu, switching to HTML view, and inserting the attribute by hand. In a theme template or a custom PHP loop, you write the attribute into your img tag directly: <img src="..." loading="eager" alt="...">. That tells the browser to treat the image exactly as it would without any lazy-loading instruction applied.
Doing this post by post is manageable for a handful of images, but it breaks down fast on a larger site. A small filter inside your theme’s functions.php can target images by class or context, removing the loading attribute programmatically wherever you need it, without touching every piece of content individually.
As a rule, only hero images and anything sitting above the fold on your most-visited templates need this treatment. Overriding too many images defeats the purpose.
Does Lazy Loading Help PageSpeed Scores?
On pages heavy with images, it can make a real difference. On lean, well-optimised pages, the gains are often marginal at best.
The metric lazy loading most directly affects is Largest Contentful Paint, because it controls when the browser fetches images. On a long blog post or a gallery page with thirty-plus images, deferring off-screen content means the browser stops competing with itself, and the images a visitor actually sees first load faster as a result. You’ll often see a genuine drop in LCP on those pages, sometimes several hundred milliseconds, which moves the needle in PageSpeed Insights. The improvement is proportional to how much off-screen image weight you were loading unnecessarily before.
Lean landing pages are a different story. If a page carries three or four compressed images and the above-the-fold content is mostly text, lazy loading does almost nothing measurable for your score. Worse, if the hero image gets tagged with loading="lazy" by accident or by a plugin applying it globally without discrimination, LCP can climb instead of fall. This is one of the more common causes of a puzzling LCP regression after installing a new WordPress speed optimisation tool. The fix is straightforward, but finding it takes time.
What to Check in PageSpeed Insights and Search Console
Reading the PageSpeed Insights diagnostics
PageSpeed Insights will flag the problem directly if it exists. Look in the Diagnostics section for a warning labelled “Lazy loaded LCP image”. That single line tells you WordPress has applied loading="lazy" to whichever image is being measured as the Largest Contentful Paint element on the page. The browser sees that attribute and waits before fetching the image, which pushes your LCP time up. On a product page where the hero shot is the first thing a visitor sees, this can add several hundred milliseconds to an otherwise reasonable score.
Run the test on your homepage, your most important landing page, and a representative product or service page separately. Do not assume one page tells the whole story, because the LCP element changes depending on what is above the fold.
Using Search Console field data
Search Console’s Core Web Vitals report gives you the field data picture. If you see a cluster of URLs moving from “Good” to “Needs Improvement” on LCP, and those pages share a similar layout with a large above-the-fold image, lazy loading is a strong candidate to investigate before anything else.
Keep an eye on CLS too. If lazily loaded images below the fold do not have explicit width and height attributes set, they can shift the layout as they load in, and that movement registers as a CLS problem rather than an LCP one. The fix differs, but the root cause in both cases comes back to how the image is being handled at the HTML level.