What lazy loading is and what this checker does

Lazy loading is a browser feature that delays downloading an image or an embedded frame until the user is about to scroll it into view. Instead of fetching every picture and every video embed the moment the page opens, the browser fetches only what is visible and waits on the rest. This checker scans a page, finds every image and iframe, and counts how many are missing the loading lazy attribute. The result is a simple inventory of which assets load eagerly when they could have waited, so you can see exactly how much unnecessary downloading happens before the page is even usable.

The mechanism is wonderfully simple to apply. Adding loading lazy to an image or iframe tag tells the browser to defer that resource. Adding loading eager, or leaving the attribute off, tells the browser to fetch it immediately. Native lazy loading is supported in every modern browser, needs no JavaScript library, and degrades gracefully in older browsers that simply load everything as before. The checker is about finding where that one small attribute is missing and where, just as importantly, it has been added in the wrong place.

Why eager-loaded assets hurt your page

Browsers have a limited number of connections and a limited amount of bandwidth, especially on mobile networks. When a long article with thirty images loads all of them at once, those downloads compete with the things the user actually needs first: the stylesheet, the hero image, the fonts, the critical scripts. The images far down the page steal bandwidth from the content above the fold, which delays the moment the page looks ready and pushes out the Largest Contentful Paint. Lazy loading the off-screen images frees that bandwidth for what matters now.

The waste is not only about speed, it is about data and cost. A visitor who reads the first two paragraphs and leaves has, on an eager page, still paid to download every image on the page, including ones they never saw. On metered mobile plans that is real money spent on bytes nobody looked at. Lazy loading means a visitor only downloads what they actually scroll to, which is fairer to them and lighter on your server and CDN bills.

The mistake that makes lazy loading backfire

Here is the single most important rule, and the one this checker is designed to enforce: never lazy load your above-the-fold images, and above all never lazy load your Largest Contentful Paint image. If you add loading lazy to the hero image, you have told the browser to wait before fetching the most important pixel on the page, which delays LCP and hurts your Core Web Vitals score. Lazy loading is a tool for off-screen content. Applied to on-screen content it does the exact opposite of what you want.

For that reason the goal is not to lazy load everything. The healthy pattern is eager loading, often paired with a high fetchpriority, for the few images visible when the page first paints, and lazy loading for everything below the fold. A page where every single image is lazy can score worse than one with no lazy loading at all. When you read this checker's output, separate the off-screen images that should be lazy from the hero and banner images that must stay eager, and judge each group on its own.

Images, iframes, and the CLS connection

Iframes deserve special attention because they are heavy. A single embedded video player, map, or social widget can pull in hundreds of kilobytes of its own scripts and styles. These almost always sit below the fold and almost always benefit from loading lazy, yet they are the embeds people most often forget to defer. The checker counts iframes separately for exactly this reason, because deferring one heavy third-party embed can do more for load time than deferring a dozen small images.

Lazy loading interacts with Cumulative Layout Shift, the metric that measures unexpected movement. When an image loads late and the page had not reserved space for it, surrounding content jumps as the image pushes it down. The fix is to always declare width and height attributes, or a CSS aspect-ratio, on every lazy image and iframe so the browser reserves the slot before the asset arrives. Lazy loading without reserved dimensions trades a speed gain for a layout-shift penalty, so treat the two as a pair.

How to read the checker output

Start with the counts. The tool reports how many images and iframes carry loading lazy, how many carry loading eager, and how many have no loading attribute at all. A page where most below-the-fold media is missing the attribute is leaving an easy win on the table. A page where the hero image carries loading lazy has an urgent problem that is actively harming LCP, even if the overall lazy count looks high.

Use the position of each asset to judge it. The first one or two images, the ones a visitor sees without scrolling, should be eager. Everything after that is a candidate for lazy. If the tool shows eager images deep in the page, those are the targets to convert. If it shows lazy images right at the top, those are the ones to switch back to eager. The point is not a perfect score on a single number, it is the right strategy applied to the right assets by position.

Performance, SEO, and AI search in 2026

Lazy loading directly supports the Core Web Vitals that feed Google's page experience signals. By cutting the bytes that compete for bandwidth at load time, it helps Largest Contentful Paint, and by encouraging reserved image dimensions it protects Cumulative Layout Shift. A lighter initial load also keeps the main thread freer, which helps Interaction to Next Paint on lower-end phones. None of these wins are dramatic on their own, but together they nudge a page from needs-improvement toward good.

For AI search, the connection is about retrieval, not display. AI crawlers that build answers for engines like ChatGPT, Perplexity, and Google AI Overviews care about your text far more than your images, and a page that does not block on loading dozens of pictures is quicker to fetch and parse within a crawler's time budget. Lazy loading keeps the page lightweight on first request, which makes it more likely an AI crawler retrieves the full content rather than timing out partway through.

Native lazy loading versus JavaScript libraries

For years the only way to lazy load was with a JavaScript library that watched the scroll position and swapped a placeholder for the real image when it came near the viewport. That approach still appears on many sites, and it carries real downsides. It depends on a script running, so if that script is slow, broken, or blocked, the images may never load at all, which is dangerous for search engines and for users with flaky connections. It also adds its own weight and its own main-thread work, the very things you were trying to reduce.

Native lazy loading, the loading lazy attribute this checker looks for, needs no script. The browser handles everything, which makes it faster, more reliable, and friendlier to crawlers, since the markup is plain HTML with no dependency on JavaScript executing. If your page still uses an old lazy-loading library with markup like a data-src attribute and a tiny placeholder image, the checker may not recognise those images as lazy, because they are not using the native attribute. That is itself a useful signal: it tells you the site is relying on a heavier, script-based approach that is usually worth replacing with the native one.

There is one compatibility note. Native lazy loading is well supported across current browsers, and in the rare older browser that does not understand the attribute, the image simply loads eagerly, so nothing breaks. That graceful fallback is another reason the native attribute has become the default recommendation, and why migrating off a custom library is low risk. When you see eager or script-based images in the checker output, treat the native attribute as the modern replacement and let the browser do the work.

What to do after you run it

Convert your below-the-fold images and iframes to loading lazy, leave the first visible image or two as eager, and give the hero image a high fetchpriority so it loads first. Add width and height attributes, or a CSS aspect-ratio, to every media element so nothing shifts as deferred assets arrive. If you run a CMS, check whether it already applies lazy loading automatically, because some do, and confirm it is not accidentally lazying your hero.

Then re-run the checker to confirm the numbers moved the right way: off-screen assets now lazy, on-screen assets still eager. Pair the result with a page-speed test to see the LCP improvement in practice, and watch your repeat measurements rather than a single sample. Lazy loading is one of the highest-return, lowest-risk performance changes available, as long as you apply it by position and never to the image that defines your largest paint.