A blog homepage displayed 50 article thumbnails. All 50 loaded on page load, regardless of scroll position. Analytics showed 70% of visitors scrolled past only 5-6 articles before leaving. Those visitors downloaded 44 images they never saw. 3MB of wasted bandwidth per visit. On mobile, initial page load took 4 seconds because the browser was busy fetching images below the fold.

Adding loading="lazy" to the below-fold images cut initial page weight from 3.5MB to 400KB. First Contentful Paint dropped from 4 seconds to 1.1 seconds. The images below the fold loaded silently as users scrolled, completely invisible to them.

Lazy loading is a simple trade: defer downloading resources that are not visible yet. The initial paint is faster because the browser focuses its bandwidth on what the user can actually see. Resources that are never scrolled to are never downloaded at all.

Native lazy loading (HTML attribute):

<img src="photo.jpg" loading="lazy" alt="Product photo" width="400" height="300">

One attribute. No JavaScript. The browser handles everything: it monitors the viewport, starts fetching the image when it is roughly 1250px from the visible area (the exact threshold varies by browser and connection speed), and renders it when the data arrives.

Supported on 96%+ of browsers as of 2024. The only notable gap is very old Safari versions (pre-15.4).

JavaScript IntersectionObserver (custom behavior):

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
}, { rootMargin: '200px' });

document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

IntersectionObserver gives you control over the trigger distance (rootMargin), lets you lazy-load non-image content (iframes, video, heavy components), and works with custom placeholder animations. But for simple image lazy loading, the native attribute is simpler and more reliable.

Lazy load aggressively:

Lazy loading is one of the easiest performance wins to measure because the before/after is dramatic:

eBay (2019 case study): Added native lazy loading to search result images. Initial payload dropped by 100 images worth of data per page. First Input Delay improved by 12%.

Chromium team measurement: Sites using loading="lazy" on below-fold images saw median First Contentful Paint improve by 200-400ms on mobile connections.

The bandwidth math: A page with 40 product images at 60KB each (WebP, properly sized) loads 2.4MB total. If only 8 images are above the fold, lazy loading reduces the initial download from 2.4MB to 480KB. The remaining 1.9MB loads incrementally as the user scrolls.

On a 3G connection (750KB/s effective), that is the difference between a 3.2-second and a 0.6-second initial image load.

Deferring work until it is needed is obviously good, and it has two specific ways of making a page worse that are easy to walk into.

Layout shift. An image that loads later arrives into a space the browser did not reserve, so everything below it jumps down. The user is reading a paragraph and it moves. This is Cumulative Layout Shift, it is a ranked Core Web Vital, and the fix is entirely mechanical: give every lazily loaded element an explicit width and height, or an aspect ratio, so the space exists before the content does.

<!-- The dimensions reserve the box. Without them, this image shifts the page. -->
<img src="hero.jpg" width="1200" height="630"
     loading="lazy" decoding="async" alt="...">

Lazy loading the thing the user is already looking at. The most common mistake, and it makes the metric that matters worse rather than better. Applying loading="lazy" to an above-the-fold hero image means the browser deliberately delays the single most important asset on the page, and Largest Contentful Paint gets worse. Anything visible without scrolling must load eagerly, and the genuinely important one should be hinted with fetchpriority="high".

Then the subtler costs:

• Deferred work still happens, later and often at a worse moment. Code split out of the initial bundle is downloaded and parsed when the user clicks, which puts network latency directly in front of an interaction they are waiting on. Prefetch on hover or on idle so the work is done before it is needed.
• A request per element instead of one request. Fifty lazily loaded images are fifty requests arriving as the user scrolls, and on a high-latency connection that can be slower overall than fetching a smaller number of well-compressed assets up front.
• Lazy content is invisible to anything that does not scroll. That includes some crawlers, in-page search, and accessibility tooling. Content that matters for should be in the initial response.