Lazy Loading Images - What It Is and When It Actually Helps

Web page diagram showing images loading progressively on scroll, illustrating the lazy loading technique for faster page load times

A lazy loading image is one that doesn't load until the user is about to see it, rather than loading everything the moment a page opens. Instead of downloading every image on a page upfront, the browser waits until each image is close to the viewport before fetching it. This one change can dramatically cut initial page load time, reduce data usage, and improve browser rendering performance, especially on image-heavy pages.

How Lazy Loading Actually Works

When a browser loads a page the traditional way, it fetches every image in the HTML, whether the user ever scrolls to see them or not. On a long article with 20 images, that means 19 of those images might be downloaded for nothing if the user reads the intro and bounces.

Lazy loading flips that default. The browser defers offscreen images, only requesting them from the server when they enter (or are about to enter) the visible viewport. The mechanism behind this in modern browsers is the Intersection Observer API, which watches element positions relative to the viewport and fires a callback when something comes into view.

Before native browser support existed, developers used JavaScript libraries to replicate this behavior manually. Today you mostly don't need them.

The image loading Attribute

The simplest way to lazy load an image is a single HTML attribute:

<img alt="A mountain trail" loading="lazy" src="photo.jpg"/>

The loading attribute accepts three values:

  • lazy — defers loading until the image is near the viewport.
  • eager — loads the image immediately, regardless of position. This is the default browser behavior even without the attribute.
  • auto — lets the browser decide. In practice, most browsers treat this the same as eager .

You can also combine loading="lazy" with width and height attributes. This lets the browser reserve the correct space for the image before it loads, preventing layout shifts that hurt your Cumulative Layout Shift (CLS) score.

<img alt="A mountain trail" height="600" loading="lazy" src="photo.jpg" width="800"/>
Always include width and height on every image you lazy load. Without them, the browser can't reserve space, and the page will jump around as images load in, hurting both user experience and your CLS score.

When Lazy Loading Genuinely Helps

Not every page benefits equally. Lazy loading makes the biggest difference in these scenarios:

  • Long-form articles and blog posts with many inline images spread across thousands of words.
  • E-commerce product listing pages showing grids of 50+ product photos.
  • Infinite scroll feeds like social timelines or news aggregators.
  • Pages targeting mobile users on slower connections, where unnecessary data transfer is expensive.
  • Image galleries and portfolio pages where most images sit far below the fold.

In all of these cases, deferring offscreen images reduces the number of HTTP requests on initial load, lowers the total bytes transferred before the page becomes interactive, and frees up bandwidth for resources that actually matter first, like CSS and JavaScript.

When You Should NOT Use It

Lazy loading has a real downside if applied carelessly. These are the situations where it hurts more than it helps:

  • Hero images and above-the-fold visuals — these are visible immediately, so lazy loading them just adds a delay. Use loading="eager" or simply omit the attribute.
  • Logos and navigation icons — these are always in view and should load instantly.
  • Pages with very few images — the overhead of the browser's lazy loading logic isn't worth it for two or three images.
  • Critical product images on landing pages — if the image is the first thing a user sees and it's central to conversion, don't defer it.
Common mistake: Adding loading="lazy" to every image on a page, including the hero. This is one of the most frequent causes of a poor Largest Contentful Paint (LCP) score. Only defer images that are genuinely offscreen on initial load.

Defer Offscreen Images: What That Actually Means

"Defer offscreen images" is the recommendation you'll see in tools like Google Lighthouse and PageSpeed Insights. It's essentially the same concept as lazy loading, just framed from an audit perspective. When Lighthouse flags it, it's telling you that images below the fold are being loaded upfront and wasting bandwidth during the critical loading window.

The fix Lighthouse recommends is exactly what we've covered: add loading="lazy" to those images. When you do, Lighthouse will stop flagging them, and your performance score will reflect the savings.

The browser typically starts fetching a lazy image when it's roughly 1,250px away from the viewport on a fast connection, and closer to 2,500px away on a slow connection. These thresholds are baked into Chromium and can vary slightly by browser, but the point is that the image starts loading a little before the user actually reaches it, so there's no visible gap.

Browser Support and Fallbacks

Native loading="lazy" support is excellent as of 2024. Here's the picture:

Browser Support Since Version
Chrome Full 76 (2019)
Firefox Full 75 (2020)
Safari Full 15.4 (2022)
Edge Full 79 (Chromium-based)
Internet Explorer None N/A

For the tiny fraction of users on unsupported browsers, the attribute is simply ignored and images load normally. No broken images, no errors. The fallback is graceful by design, which means you can add loading="lazy" today without worrying about breaking anything for anyone.

If you need to support older browsers or want more control over the loading threshold, JavaScript-based lazy loading libraries like vanilla-lazyload are lightweight options that use the Intersection Observer API directly.

Lazy Loading and Core Web Vitals

Lazy loading directly affects two of Google's Core Web Vitals:

  • Largest Contentful Paint (LCP) — this measures how long it takes for the largest visible element to render. If your LCP element is an image and you've accidentally lazy loaded it, your LCP score will tank. Never lazy load your LCP image.
  • Cumulative Layout Shift (CLS) — lazy loading can cause layout shifts if images don't have reserved dimensions. Setting width and height attributes prevents this.

Used correctly, lazy loading improves both metrics. Used incorrectly (lazy loading the hero, or skipping dimensions), it hurts them. The rule is simple: lazy load everything below the fold, eager load everything above it.

You can verify which images are being lazy loaded and whether your LCP image is affected by running a PageSpeed Insights report. It will explicitly call out the LCP element and flag any lazy loading conflicts.

Tool for analyzing and improving image loading performance

Speed up your pages by fixing lazy loading image issues

If slow image loading is hurting your site's performance, our free tool can help you identify and address lazy loading image problems before they cost you rankings or conversions.

Try Our Free Tool →

No, when implemented correctly, lazy loading does not hurt SEO. Googlebot supports native lazy loading via the loading="lazy" attribute and can crawl and index lazy loaded images. The risk comes from JavaScript-based implementations that block crawlers. Stick with the native HTML attribute and you won't have indexing issues. Google has confirmed this in its developer documentation.

WordPress has added native lazy loading automatically since version 5.5, released in August 2020. It adds loading="lazy" to all images by default, except the first image in a post, which it treats as potentially above the fold. You generally don't need a plugin for this. If you're on an older theme or page builder, check whether your images are getting the attribute in the rendered HTML.

The native loading attribute only works on <img/> and <iframe> </iframe> elements. CSS background images are not supported. To lazy load a CSS background image, you need a JavaScript solution, typically using the Intersection Observer API to add a class to an element when it enters the viewport, and then applying the background image via that class in your CSS.

They are opposites. Lazy loading delays an image fetch until the user is near it. Preloading tells the browser to fetch a resource as early as possible, even before the HTML parser would normally discover it. You use <link rel="preload"/> for critical above-the-fold images like your hero, and loading="lazy" for everything below the fold. Using both strategically gives you the best of both worlds for browser rendering performance.

Yes. The loading="lazy" attribute works on <iframe> </iframe> elements in all modern browsers, which is especially useful for embedded YouTube videos, maps, or third-party widgets. For <video> </video> elements, the equivalent is the preload="none" attribute, which tells the browser not to download any video data until the user interacts with the player.

In Chromium-based browsers, the threshold is roughly 1,250px below the viewport on a fast connection and around 2,500px on a slow or 2G connection. This buffer ensures images load before the user actually scrolls to them, so there's no visible blank space or delay. Firefox uses similar thresholds. These values are internal browser decisions and are not configurable via HTML alone.