The fix, in one snippet
<img src="/img/detail.webp" width="800" height="600" loading="lazy" decoding="async" alt="...">Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
We count <img> elements carrying loading="lazy" against the total number of images found. The check reports when a page has images but none of them are deferred.
It does not attempt to judge which images are above the fold, because that depends on the viewport. The absence of lazy loading anywhere on a page with many images is the signal.
Why it matters
Native lazy loading defers off-screen images until the reader scrolls near them. On an image-heavy page that can remove most of the bytes from the initial load, which directly improves Largest Contentful Paint, one of the Core Web Vitals that feeds into ranking.
It costs one attribute and is supported by every current browser, with graceful degradation in older ones: an unrecognised attribute is simply ignored and the image loads as before.
The one thing to avoid is lazy-loading the hero image. Deferring the largest visible element delays exactly the paint the metric measures, which makes the score worse rather than better.
How to fix it
Defer everything below the fold and let the first visible image load eagerly, with explicit dimensions so the layout does not shift as images arrive:
<!-- hero: load immediately, and hint that it is the LCP element -->
<img src="/img/hero.webp" width="1200" height="630" fetchpriority="high" alt="...">
<!-- everything further down -->
<img src="/img/detail.webp" width="800" height="600" loading="lazy" decoding="async" alt="...">Always set width and height: without them a lazy-loaded image has no reserved space, and the page jumps as it appears, which shows up as Cumulative Layout Shift. The attributes do not fix the displayed size; they give the browser the aspect ratio so it can reserve the right box while the file is still arriving.
If your images are generated by a CMS that does not emit dimensions, adding them is usually a one-line template change with a larger effect on the layout-shift score than anything else available.
Where this fits
Images not lazy-loaded is check 3 of 3 that the seo & site health audit runs under images and page weight, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Oversized HTML documents (medium), where a very large HTML document delays rendering and can be truncated by crawlers before the end of the page is read. An attacker who has that does not need this, so it is the better use of the same hour.
Found in the same scan
The seo & site health audit reports this alongside checks from other categories that are at least as serious, including Broken internal links, where an internal link that returns an error is a dead end for the reader and a wasted request for the crawler, and Crawl errors (4xx / 5xx), where uRLs reached during the crawl that returned a client or server error. A single run of seo & site health audit answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Images not lazy-loaded (low severity)
Scanner check id: seo-image-loadingThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.