Lazy loading images is one of the most reliable ways to make a WordPress site feel faster. Done correctly, it stops the browser from downloading images the visitor may never scroll to, freeing up bandwidth for the content that actually matters first. Done carelessly, lazy loading in WordPress can quietly wreck your Largest Contentful Paint (LCP) and introduce visible layout shift. This guide covers how to lazy load the right way, what you should never lazy load, and how to avoid the traps that turn a speed optimization into a speed problem.
What lazy loading actually does
Lazy loading defers the download of off-screen images until the user scrolls near them. Instead of the browser fetching all 30 images on a long article at once, it fetches only the few that are visible, then loads the rest on demand. The payoff is a lighter initial page, fewer requests competing for bandwidth during the critical first moments, and a faster time to interactive on image-heavy pages.
Since WordPress 5.5, core has added loading="lazy" to most images automatically. That is a good baseline, but it is also where most sites get into trouble: WordPress applies it broadly, including to images that should load immediately. The difference between fast and slow is not whether you lazy load, it is what you exclude from it.
The one rule that matters most: never lazy load your LCP image
Your Largest Contentful Paint element is usually the biggest thing visible when the page first renders, often a hero image or a featured image at the top of a post. If you lazy load that image, you are telling the browser to wait before fetching the single most important pixel on the screen. The result is a slower LCP score and a page that feels sluggish, even though your intention was to speed it up.
The correct approach is the opposite of lazy loading for above-the-fold images: you want them loaded eagerly, and ideally preloaded with a high fetch priority. Modern browsers support fetchpriority="high" on the LCP image, which nudges it to the front of the download queue. Everything below the fold gets loading="lazy"; the hero does not.
If you are chasing a good LCP score specifically, our companion guide on how to improve Largest Contentful Paint in WordPress goes deeper on preloading, fetch priority, and server response time. Lazy loading and LCP tuning are two halves of the same job.
Avoid layout shift: always reserve space
The second most common lazy-loading mistake is causing Cumulative Layout Shift (CLS). When an image loads late and the browser did not know its dimensions in advance, surrounding content jumps as the image pushes it down. This is jarring for users and penalized by Core Web Vitals.
The fix is simple but essential: every image should have explicit width and height attributes (or a CSS aspect-ratio) so the browser can reserve the correct space before the image arrives. WordPress usually adds these automatically for media-library images, but page builders, custom themes, and background images often omit them. If you are seeing content jump on load, start there. Our guide to fixing Cumulative Layout Shift in WordPress walks through diagnosing and eliminating these shifts.
What to lazy load and what to exclude
A good lazy-loading setup is really an exclusion list. Here is the practical breakdown:
- Lazy load: below-the-fold content images, gallery thumbnails, images deep in long posts, and anything a visitor has to scroll to reach.
- Do NOT lazy load: your hero or LCP image, your logo, above-the-fold images, and any image that is part of the first viewport.
- Be careful with: iframes and embeds. Lazy loading YouTube embeds and maps is usually a big win, but test that interactive embeds still behave.
- Watch out for: CSS background images. Native lazy loading does not apply to them, so heavy hero backgrounds need a different technique (preloading, not deferral).
The takeaway: lazy loading should be aggressive for off-screen media and completely hands-off for the first screen. Any tool worth using lets you exclude specific images or the first N images from lazy loading.
Native browser lazy loading vs. JavaScript lazy loading
There are two ways to lazy load in WordPress, and it helps to know which one you are relying on.
| Approach | How it works | Best for |
|---|---|---|
Native (loading="lazy") |
Built into the browser and WordPress core; no JavaScript required | Standard content images; the sensible default for most sites |
| JavaScript-based | A script watches the viewport and swaps in images as they approach; can lazy load backgrounds and add fade-in effects | Background images, sliders, and cases where you need finer control |
Native lazy loading is faster, lighter, and free of the “no image until JavaScript runs” failure mode. JavaScript lazy loading is more powerful but adds its own overhead and can hurt performance if the script is heavy or blocking. For most WordPress sites in 2026, native lazy loading plus a smart exclusion list beats a bloated JavaScript library. If you do use a script-based approach, make sure it is lightweight and does not become part of your unused JavaScript problem.
Lazy loading is one layer, not the whole strategy
Lazy loading controls when images download. It does nothing about how big they are. A 2 MB unoptimized JPEG that loads lazily is still a 2 MB JPEG when the user scrolls to it. Real image performance combines three things:
- Proper lazy loading with the LCP image excluded.
- Modern formats like WebP and AVIF, which are dramatically smaller than JPEG or PNG at the same quality. See WebP vs AVIF for WordPress to choose.
- Right-sizing so mobile visitors are not downloading desktop-resolution images.
If you want the full picture on compression, formats, and responsive sizing, our guide to optimizing images for WordPress covers the workflow end to end. Lazy loading is the finishing touch on top of good image optimization, not a substitute for it.
Doing it the right way with Speed of Light
You can absolutely handle lazy loading with careful manual configuration and native WordPress behavior. But the reason so many sites get it wrong is that lazy loading, LCP exclusion, format conversion, and layout-shift prevention are usually spread across several plugins that do not talk to each other.
Speed of Light handles the whole image pipeline in one place. It converts your images to WebP (with AVIF support) on your own server, so there is no image CDN and no per-image metering. It detects your LCP image and preloads it with high fetch priority instead of lazy loading it, and it applies lazy loading everywhere it genuinely helps. It also tunes LCP and CLS so lazy loading does not introduce layout shift, and its first-party Real-User Monitoring shows you the actual field impact on your visitors rather than a lab guess.
What makes Speed of Light unusual is that image optimization is not the whole product. The same single license also includes a disk full-page cache served before WordPress even boots, full-page edge caching on Cloudflare’s free plan, and a native Redis object cache with a GUI. Critical CSS, unused-CSS removal, and ad-safe JavaScript delay come with it too. If lazy loading is one item on a longer speed to-do list, it is worth comparing an all-in-one approach against stacking single-purpose plugins in our roundup of the best WordPress caching plugins in 2026.
Speed of Light is anonymous-cache and WooCommerce-safe by design (logged-in sessions bypass the cache), which matters because aggressive optimization on a store can break carts and checkout. Pricing starts at $49/year for a single site, with a 14-day money-back guarantee.
Frequently asked questions
Does WordPress lazy load images by default?
Yes. Since WordPress 5.5, core automatically adds loading="lazy" to most content images. The problem is that it can also lazy load your above-the-fold hero image, which hurts LCP. The right setup keeps native lazy loading but explicitly excludes the first viewport, especially the LCP element.
Why is lazy loading hurting my PageSpeed score?
Almost always because your LCP image is being lazy loaded, so the browser delays fetching the most important image on the page. Exclude your hero or featured image from lazy loading, preload it, and give it fetchpriority="high". If your score dropped after enabling a lazy-loading plugin, this is the first thing to check.
Should I lazy load background images?
Native loading="lazy" does not apply to CSS background images, so they are not lazy loaded unless you use a JavaScript technique. For above-the-fold backgrounds you generally want the opposite anyway: preload them so they render fast. Only defer decorative backgrounds that sit well below the fold.
Is native lazy loading better than a plugin?
For the majority of sites, native browser lazy loading is faster and lighter than a JavaScript library. A plugin is still valuable, but its best job is managing the exclusion list, handling LCP preloading, and pairing lazy loading with WebP/AVIF conversion, not replacing the browser’s built-in behavior with heavy scripts.
Does lazy loading help mobile performance?
Significantly. Mobile connections benefit most from downloading fewer images up front. Combined with WebP/AVIF and right-sized images, lazy loading is one of the highest-impact mobile speed wins. See our guide on improving mobile page speed in WordPress for the full mobile checklist.
Want lazy loading, WebP conversion, LCP preloading, and three layers of caching handled correctly out of the box? Try Speed of Light and get the full image pipeline plus disk, edge, and object caching in a single license.
