How to Check Lazy Loading Is Working

What working lazy loading looks like

Lazy loading means the browser holds back requests for images that are not near the visible part of the page, and fetches each one only as the visitor scrolls towards it. The aim is simple: spend the first seconds of a visit on the content people can actually see, and skip downloading images that many visitors never reach.

When it is working, a page load has a clear shape. The first batch of image requests covers the first screen plus a margin below it. Further requests then arrive in small groups as you scroll. When it is broken, you see one of two shapes instead: every image on the page requested at once, before you touch the scroll bar, or the main image near the top arriving late because it was told to wait.

Modern browsers support lazy loading natively through the loading="lazy" attribute on <img> and <iframe> elements. Older sites often use a JavaScript library instead, which keeps the real address in an attribute such as data-src and copies it into src when the image comes close. Both approaches can be tested the same way, by watching the network requests.

How far ahead browsers load lazy images

Native lazy loading does not wait until an image is on screen. Each browser starts fetching a lazy image when it comes within a set distance of the viewport, so it has time to arrive before the visitor reaches it. That distance is why the first batch of requests includes images below the fold, and why a short page can look as if nothing is lazy at all.

Chrome uses a margin of about 1,250 pixels on fast connections and about 2,500 pixels on slower ones. Firefox and Safari use their own, generally smaller, margins. The exact numbers are browser internals and can change between versions, so treat them as a guide rather than a target.

The last row surprises people. Browsers only defer lazy images when scripting is enabled, as a privacy measure, because scroll-based loading could otherwise be used to track how far someone reads. So if you test with JavaScript disabled, every image loads, and that is expected.

How to test it in Chrome DevTools

The Network panel gives you the clearest answer. Open DevTools with F12, or Cmd+Option+I on a Mac, and choose the Network tab. Click the Img filter so only image requests show, tick Disable cache, and make sure you are scrolled to the very top before reloading. If the page restores your old scroll position on reload, open it in a new tab instead.

Watch the request count at the bottom of the panel. Note the number when the page finishes loading, then scroll slowly. If lazy loading works, new rows appear as you go and the count climbs in steps. Right-click a column heading and turn on Priority and Initiator: lazy images are usually requested at Low priority, and the initiator shows whether the request came from the HTML parser or from a script.

Count lazy and eager images from the Console

Paste this into the Console on the page you are testing. It lists every image, whether it has the attribute, whether it has already been fetched, and how far down the page it sits.

const rows = [...document.images].map(img => ({
  src: (img.currentSrc || img.src || img.dataset.src || '').split('/').pop().slice(0, 40),
  loading: img.getAttribute('loading') || '(none)',
  loaded: img.complete && img.naturalWidth > 0,
  top: Math.round(img.getBoundingClientRect().top + scrollY)
}));
console.table(rows);
console.log('loaded on first view:', rows.filter(r => r.loaded).length, 'of', rows.length);

Run it once straight after a fresh load, without scrolling. Images far down the page, say with a top value above 3,000, should show as not loaded. If they are all loaded, the attribute is missing or something is overriding it.

Check the HTML the server sends

The Elements panel shows the page after scripts have run, which can hide where an attribute came from. To see what the server actually sends, fetch the page from the command line and count the attributes:

curl -s https://www.example.com/category/shoes/ | grep -o '<img[^>]*>' | head -20
curl -s https://www.example.com/category/shoes/ | grep -c 'loading="lazy"'
curl -s https://www.example.com/category/shoes/ | grep -c 'data-src='

If the server HTML has loading="lazy" but the browser loads every image, a script is setting the source early or replacing the markup. If the server HTML has no attribute at all, the theme or platform is not adding it, and the fix belongs in the template. Our image optimisation audit runs the same check across a whole page and flags each image that is eager when it could wait.

Making sure the first screen is not delayed

The more common mistake today is not too little lazy loading but too much. When a theme, plugin or component adds loading="lazy" to every image, the hero image, the logo and the first product photos are held back too. The browser does not know they are visible until layout is worked out, so their requests start later than they should. That delay feeds straight into Largest Contentful Paint.

In the Network panel, find your hero image and look at when its request started compared with the HTML document. If it starts after a run of scripts and stylesheets, or after smaller images lower down, it has been held back. In the Elements panel, select the image and read its attributes. The first-screen image should look like this:

<img src="/images/hero-1200.webp"
     srcset="/images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="600"
     fetchpriority="high" alt="Garden studio with open doors">

No loading attribute at all is fine, because eager is the default. Adding fetchpriority="high" to the single most important image tells the browser to fetch it ahead of other images. Images further down keep loading="lazy" and should also carry width and height, so the space is reserved and nothing jumps when they arrive. See fixing missing image dimensions if they do not.

Lighthouse checks this for you. Depending on the version, it either shows an audit saying the Largest Contentful Paint image was lazily loaded, or an LCP request discovery insight that reports whether lazy loading was applied to the LCP image. Either warning means the attribute is on the wrong image. The full LCP picture is covered in our guide to fixing slow LCP.

Why a test fails, and what each result points to

CSS background images deserve a note. The loading attribute only works on image and iframe elements, so a hero or section background set in CSS is fetched as soon as the stylesheet applies to an element on the page. If a long page uses many decorative backgrounds, either swap them for real images with the attribute, or use a small script that adds the background class when the section comes into view.

Duplicate handling is another common one. A site that moved to native lazy loading but kept an old script can show each image twice in the Network panel. Pick one method. Native lazy loading is now supported in Chrome, Edge, Firefox and Safari, so for most sites the script can go. Our guide to loading lazy not working covers each of these fixes in detail.

Platform notes

WordPress

WordPress has added loading="lazy" to content images since version 5.5. Since 5.9 it skips the first content image, and since 6.3 it also tries to add fetchpriority="high" to the image most likely to be the LCP element. Optimisation plugins often add their own lazy loading on top, with settings to exclude a number of leading images or images by class. If your hero is set by a page builder as a background, it will not be affected by any of this, so test it separately. More detail is in fixing images on WordPress.

Shopify

Most current Shopify themes use the image_tag Liquid filter, which accepts a loading value. Themes usually set it to lazy for everything except the first section. Check the theme's section files if collection pages load all product images at once.

{{ product.featured_image | image_url: width: 600 | image_tag: loading: 'lazy', sizes: '(min-width: 990px) 25vw, 50vw' }}

Next.js

The next/image component lazy-loads by default. The main above-the-fold image should be marked with the priority prop, or the newer preload prop in recent versions, which removes lazy loading and adds a preload hint. If every image on a page has that prop, nothing is lazy any more.

The fix, step by step

Edge cases worth knowing

• Tabs, accordions and hidden menus. Lazy images inside an element with display: none are not loaded until it is shown. That is usually what you want, but it can make an image appear late when a visitor opens a tab.
• Very wide or very tall layouts. On a large monitor more of the page falls inside the loading margin. Test at a typical laptop size as well as your own screen.
• Printing. Browsers load lazy images before printing, so a print preview is not a useful test.
• Images added by JavaScript. When a script creates an image, set loading before src. Setting the source first starts the request straight away.
• Iframes. Embedded maps and videos can take loading="lazy" too, and they often weigh more than images. Check them in the Network panel with the All filter.
• Search engines. Google renders pages with a tall viewport, so native lazy images are found. Scripts that only load images on a real scroll event may hide them from crawlers.

Keeping lazy loading correct

Lazy loading tends to break quietly, after a theme update, a new page builder block or a change of optimisation plugin. Build a short check into your routine:

• After any theme, plugin or template change, repeat the Network panel test on one long listing page and one key landing page.
• Keep a note of how many images each test page requests on first load. A jump from 8 to 60 is easy to spot.
• Run Lighthouse on your main templates monthly and look for a lazy-loaded LCP image or offscreen image warnings.
• When you add a new hero or slider, check its first image has no lazy attribute and, if it is the main image, has fetchpriority="high".
• Watch your field data for LCP in Search Console's Core Web Vitals report, which groups similar URLs together.

If LCP worsens after a change, check lazy loading first. It is one of the quickest regressions to find and one of the quickest to undo. The Core Web Vitals assessment guide explains how to read the field data once the fix is live.