Image lazy loading explained: what it fixes and what it can break
TL;DR: Lazy loading defers loading an image until it is actually about to become visible in the viewport (as the visitor scrolls toward it) rather than loading every image on the page immediately regardless of whether the visitor will ever actually scroll far enough to see it, genuinely reducing initial page load time and bandwidth usage for pages with many images below the visible fold. The specific mistake that undermines this benefit, and can directly hurt performance rather than help it: applying lazy loading to your largest, above-the-fold image (commonly a hero image), since this specific image is exactly what Largest Contentful Paint (covered in our dedicated Core Web Vitals guide) measures, and deferring its load actually delays LCP rather than improving overall performance.
What lazy loading actually does
By default, without lazy loading, a browser begins downloading every image referenced on a page as soon as it encounters the image tag while parsing the HTML, regardless of whether that image is immediately visible in the viewport or sits far below the fold, requiring significant scrolling to ever actually reach. For a content-heavy page with many images, a long article, a large product gallery, this means a visitor's initial page load competes bandwidth and processing resources across every single image on the entire page simultaneously, even the ones at the very bottom that a meaningful share of visitors may never actually scroll down far enough to see at all.
Lazy loading changes this by deferring the actual download of images that are not yet visible, only triggering their load as the visitor scrolls close enough that the image is about to enter the viewport, meaning the initial page load only needs to handle the images genuinely, immediately visible, with everything else loading progressively and only as actually needed.
Why it genuinely helps for most images
For any image positioned below the initial visible viewport, on first page load, deferring its download genuinely reduces the total data and processing competing for resources during that critical initial load period, directly improving initial page load speed and reducing unnecessary bandwidth consumption for visitors who do not scroll through the entire page, a meaningful, genuine performance benefit for the overwhelming majority of images on a typical content-rich page.
The specific mistake: lazy loading your LCP image
This is the genuinely important exception worth understanding clearly. Largest Contentful Paint (LCP), one of the three Core Web Vitals covered in our dedicated guide, specifically measures how quickly the largest visible content element, very commonly a large hero image positioned prominently above the fold, finishes rendering. If that specific image is lazy-loaded, the browser deliberately delays starting its download until some triggering condition (often, in a poorly implemented lazy-loading setup, requiring JavaScript to first execute and determine the image is in the viewport before even beginning the download), which directly and measurably delays exactly the metric LCP is designed to capture, since the image the browser is measuring time-to-render for is the same one whose download start was artificially, unnecessarily deferred.
This produces a genuinely counterproductive outcome: a performance optimization technique, applied indiscriminately to every image on a page including the one specific image where it actively hurts the most visible, most measured performance metric, directly working against the broader performance goal lazy loading is meant to serve.
How WordPress handles lazy loading by default
Current versions of WordPress core include native lazy loading support, automatically adding the loading="lazy" HTML attribute to images, but critically, WordPress core's own implementation is specifically designed to skip applying this attribute to the very first, typically largest image detected on a page, precisely to avoid the LCP-delaying mistake described above, a sensible, deliberate default behavior. However, this automatic, sensible exclusion can be undermined or bypassed in a few common situations: a theme or page builder rendering the hero image in a way that WordPress's own detection logic does not correctly recognize as "the first image," a lazy loading plugin (separate from and potentially conflicting with WordPress core's own native handling) applying its own, less discriminating logic that does not include this same specific exclusion, or a background image implemented via CSS rather than a standard image tag, which WordPress's native lazy loading logic does not govern at all, potentially being lazy-loaded or otherwise mishandled by a separate mechanism without the same built-in safeguard.
Checking whether your setup has this mistake
Directly inspecting your page's HTML source (or using browser developer tools) for your specific hero or largest above-the-fold image, checking whether it has a loading="lazy" attribute applied, is a quick, direct way to confirm whether this specific mistake is present on your site. Complementing this with a PageSpeed Insights check (covered in our dedicated comparison guide) specifically looking at your LCP element and score, and checking whether PageSpeed Insights' own diagnostic suggestions flag anything related to lazy loading or the specific LCP element's loading behavior, provides direct, confirming evidence either way rather than relying purely on manual inspection alone.
Other things lazy loading can break if misconfigured
Images inside a carousel or slider not yet visible but expected to load promptly. Some interactive components expect their images to already be loaded and ready when a user interacts with them (clicking to the next slide, for example), and if those images are lazy-loaded and the specific triggering logic does not correctly account for this interactive context, a visitor can experience a visible, jarring delay or a blank space when interacting with the component, rather than the image being smoothly, already available. Images referenced by print stylesheets or other non-standard rendering contexts. Lazy loading is specifically designed around standard browser viewport scrolling behavior, and images intended for contexts outside this standard model (a print-specific stylesheet, for example) can sometimes fail to load correctly if lazy loading logic does not correctly account for these non-standard rendering contexts. SEO-related image indexing concerns, though this is a smaller, more theoretical concern with modern search engine crawling behavior, which generally handles standard, correctly implemented lazy loading well; a poorly implemented, non-standard lazy loading approach (rather than the standard, well-supported loading="lazy" attribute) could theoretically create image indexing complications worth being aware of if using a custom or unusual lazy loading implementation rather than the standard, well-supported browser-native approach.
A comparison table
| Image position/type | Should be lazy loaded? |
|---|---|
| Hero image / largest above-the-fold image (your LCP element) | No |
| Images further down a long article or page | Yes |
| Product gallery images beyond the first few visible ones | Yes |
| Images inside an interactive component expected to be immediately ready | Carefully, test interaction behavior specifically |
| Background images implemented via CSS | Verify separately, not governed by standard image lazy loading |
FAQs
Does WordPress's built-in lazy loading require any plugin or manual configuration?
No, current WordPress versions apply sensible, native lazy loading automatically by default, including the exclusion for the likely-LCP first image, meaning many sites do not need any additional plugin specifically for basic lazy loading functionality, though verifying it is working correctly (as covered above) remains worthwhile regardless.
If I use a separate lazy loading plugin, does it conflict with WordPress's native handling?
It can, depending on the specific plugin and how it is configured; some plugins are specifically designed to work alongside or replace WordPress's native handling cleanly, while others may apply lazy loading more indiscriminately without the same LCP-image exclusion, worth checking your specific plugin's documentation and testing your actual LCP element's behavior directly rather than assuming compatibility.
Does lazy loading affect image SEO or Google Image Search visibility?
Standard, correctly implemented lazy loading using the native loading="lazy" attribute is well understood and properly handled by modern search engine crawlers, generally not a meaningful SEO concern; a non-standard, JavaScript-dependent lazy loading implementation that does not use this standard attribute carries somewhat more theoretical risk of being handled less reliably by crawlers.
Can I manually mark a specific image as excluded from lazy loading if my theme or plugin doesn't automatically do this correctly?
Yes, adding loading="eager" explicitly to a specific image (overriding a lazy default that might otherwise be applied) is the standard, direct way to ensure a specific important image, like your hero image, loads immediately regardless of what a broader, less discriminating lazy loading configuration might otherwise apply to it.
Does lazy loading apply to videos as well as images?
A similar underlying concept and browser-native support exists for deferring video loading, though the specific implementation details differ somewhat from image lazy loading; if your site includes video content, checking whether it is being appropriately handled (particularly if a video is your actual LCP element on some pages) follows the same general principle covered here for images specifically.
How do I know which specific image is actually my LCP element?
PageSpeed Insights and similar tools (covered in our dedicated comparison) typically identify and specifically call out the detected LCP element directly in their report, the most reliable, direct way to confirm which specific image (or other content element) you need to ensure is not inadvertently lazy-loaded.
Does this LCP-lazy-loading mistake happen more often with certain page builders or themes?
It can be more common with page builders or themes that render hero sections or background images in less standard ways than a straightforward, simple image tag, since WordPress core's own automatic detection logic is built around recognizing standard image tag patterns, making it worth specifically testing and verifying this behavior on your particular theme/page builder combination rather than assuming the native safeguard automatically applies correctly in every possible implementation.
Conclusion
Lazy loading provides a genuine, meaningful performance benefit for the majority of images on a typical content-rich page, deferring their download until actually needed rather than competing for resources during initial page load regardless of visibility. The specific, important exception is your largest above-the-fold image, typically your LCP element, where lazy loading directly and measurably works against the Core Web Vitals metric it is otherwise meant to help improve.
Verify your specific hero or largest above-the-fold image is genuinely excluded from lazy loading, either through WordPress's sensible native default behavior or explicit manual configuration, particularly if using a page builder or theme that might render this image in a way that bypasses the standard, automatic safeguard.
HostCloud's hosting includes image optimization tooling that correctly handles this specific LCP-image exclusion as part of our broader performance configuration, helping avoid this common, counterproductive misconfiguration. Plans start at ₹99 a month at https://hostcloud.in.