Most websites load every image on a page at once, regardless of whether the visitor ever scrolls down far enough to see them. On a page with twenty images, that means the browser is fetching all twenty from the moment someone lands – even if they only read the first three sections and leave. That unnecessary work adds weight to the initial load and slows down the experience for everyone.
Lazy loading changes this by deferring the loading of images and iframes until they’re about to enter the viewer’s screen. Instead of requesting every asset upfront, the browser only loads what’s immediately visible. Everything else waits. The result is a faster initial page load, lower bandwidth usage, and better scores in Core Web Vitals – particularly Largest Contentful Paint and Time to Interactive.
The underlying mechanism is a standard HTML attribute supported by every modern browser, not something tied to one platform – most website builders and content management systems apply it automatically or make it available with a simple setting. On WordPress specifically, it’s been on by default since version 5.5, so it’s worth understanding how it works there and where it falls short.
How Native Lazy Loading Works
The mechanism is the loading="lazy" attribute on an <img> tag – a browser standard, not a feature exclusive to any single platform. When it’s present, the browser holds off on fetching that image until it’s within a certain distance of the viewport, rather than requesting it the moment the page loads.
This is handled natively in all modern browsers without any JavaScript. It’s a pure HTML attribute, which means it’s reliable, lightweight, and doesn’t require any extra script to function. On WordPress, the platform adds this attribute automatically to images inserted via the block editor or added through a theme or plugin – as long as you’re running WordPress 5.5 or later (which you almost certainly are), your images already have it applied with no configuration needed.
There is one deliberate exception worth knowing about regardless of platform: the first image in the content area is typically excluded from lazy loading. That first image is likely part of the above-the-fold content, and lazy loading it would cause a visible delay – the browser would start fetching it later than it should, which hurts LCP rather than helping it. WordPress makes this call automatically, and it’s the correct behaviour on any platform.
What Isn’t Lazy Loaded by Default
Native lazy loading typically covers images inserted through a standard content editor, but it doesn’t cover everything. A few areas are commonly missed on most platforms:
- Iframes – Embedded YouTube videos, Google Maps, and other iframes don’t always receive the lazy loading attribute automatically, depending on how they’re inserted.
- Images added via CSS – Background images set in stylesheets are not HTML img elements, so the loading attribute doesn’t apply to them at all.
- Images added by plugins or third-party embeds – Content inserted by an add-on may output images without going through your platform’s standard image functions, so it may not receive the attribute.
- Older or heavily customised themes – On WordPress, if your theme doesn’t use standard WordPress template functions for images, native lazy loading may not apply.
For most modern sites using a standard editor and theme, native lazy loading covers the majority of cases. But if your site uses a lot of embedded video or relies on a heavily customised template, it’s worth testing what’s actually loading when.
How to Check Whether Lazy Loading Is Working
You don’t need any extra tool to check this. Open any page on your site, right-click on an image that appears below the fold, and choose Inspect. Look at the <img> tag in the HTML panel. If it includes loading="lazy", native lazy loading is active on that image.
You can also use Google PageSpeed Insights to see whether lazy loading is flagged as an opportunity on your site. If PageSpeed shows “Defer offscreen images” as an issue, it means some images below the fold are still being loaded immediately – either because the lazy loading attribute is missing, or because something is overriding the default behaviour.
In Chrome DevTools, you can simulate a slow connection under the Network tab and watch the waterfall as you scroll. Images that only start loading when you scroll toward them are lazy loading correctly.
Improving Lazy Loading and Prioritising Your Above-the-Fold Image
Lazy loading is only half the picture. The counterpart is fetchpriority – another standard HTML attribute that tells the browser to fetch a specific image as early as possible. Applied to your largest above-the-fold image (usually the one that determines your LCP score), it works alongside lazy loading rather than against it: defer what’s not needed, and prioritise what is.
On WordPress, the Performance Team maintains the Performance Lab plugin, a suite of experimental performance features that extend what WordPress does natively – including automatically identifying and marking the above-the-fold LCP image with fetchpriority="high". To use it, install Performance Lab from the WordPress plugin directory, then go to Settings > Performance in your dashboard. You’ll see individual modules you can enable selectively – the Image Prioritizer and Speculative Loading modules are a reasonable starting point, then check PageSpeed Insights again after a day or two to see the impact.
Using a Caching Tool to Extend Lazy Loading
If your site already uses a caching or performance-optimisation tool, you may have additional lazy loading options available without installing anything extra. On WordPress, LiteSpeed Cache includes a dedicated lazy load setting under LiteSpeed Cache > Page Optimization > Media. This setting applies lazy loading more broadly, including to images that might not be caught by the platform’s native implementation.
When using a caching tool’s lazy load setting alongside native lazy loading, there’s generally no conflict – the tool either adds the attribute where it’s missing or replaces standard img tags with a JavaScript-powered alternative. The most common trade-off with JavaScript-based lazy loading is that it introduces a small dependency on script execution, whereas native lazy loading requires nothing extra from the browser.
In most setups I work with, enabling a caching tool’s lazy load option and leaving native lazy loading in place produces the best coverage without meaningful downsides. If you’re also converting your images to WebP and compressing them properly, the combined impact on load time becomes significant.
Common Mistakes to Avoid
- Lazy loading your hero image – If your featured image or hero section appears above the fold, it should load immediately. Applying lazy loading to it will delay the LCP element and hurt your score. Most platforms avoid this by default, but some tools apply lazy loading globally without this exception in place.
- Disabling native lazy loading without a replacement – Some older performance guides suggest disabling native lazy loading and using a JavaScript tool instead. Unless there’s a specific reason, this adds unnecessary complexity.
- Assuming lazy loading fixes all performance issues – Lazy loading addresses offscreen image loading, but it won’t fix large image file sizes, unoptimised code, or slow server response times. It works best as part of a broader approach to improving website speed.
When a Dedicated Lazy Load Tool Makes Sense
For most sites, the combination of native lazy loading and a caching tool’s media settings is sufficient. A dedicated lazy load tool is worth considering if you have a site with a large number of iframes – particularly embedded videos – or if you’re using a heavily customised template that outputs images outside of your platform’s standard functions.
On WordPress, plugins like a3 Lazy Load or Flying Scripts extend lazy loading to iframes and can be configured to exclude specific elements. Before installing one, check whether your caching tool already provides this coverage – many do.
Conclusion
Lazy loading is likely already active on your site if you’re running a reasonably modern platform. Alongside it, enabling GZIP compression is another quick server-level win worth checking – it reduces the size of HTML, CSS, and JavaScript files before they reach the browser. The most practical next step is to run your site through PageSpeed Insights and check whether offscreen images are flagged, following the step-by-step guide to making a website for the wider context – then decide whether your caching tool’s lazy load setting or the Performance Lab plugin gives you the additional coverage you need.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.