Defer Offscreen Images: Lazy-Loading Done Right

This check flags images that sit offscreen at load, further down the page, in a footer, in tabs the user has not opened, yet download immediately anyway. Those bytes crowd out the images and resources the visible viewport actually needs, pushing back Largest Contentful Paint and inflating total page weight. Deferring them frees the initial load to serve what the user can see right now.

What this check flags and why it matters

The audit finds images that render below the fold but are fetched eagerly during the first load. On a long page that can be dozens of full-size images the visitor may never scroll to, all fighting for the same connection as the hero and the first paragraph. The stakes are a slower LCP, more wasted mobile data, and a page that feels heavy before it has shown anything, all fixable with a single attribute, provided you apply it in the right place. On a content-heavy page, deferring offscreen images can cut the initial payload by half or more, because the visitor pays only for what they actually scroll to rather than the entire library up front.

The fix, and the one image you must not touch

Native lazy loading is one attribute. The whole game is applying it to below-the-fold images and leaving above-the-fold ones alone.

<!-- Hero / LCP image, above the fold: load eagerly, hint high priority -->
<img src="/hero.webp" width="1200" height="600" alt="..."
     fetchpriority="high">

<!-- Everything below the fold: defer it -->
<img src="/gallery-07.webp" width="800" height="600" alt="..."
     loading="lazy">

Two habits save you grief. Always set explicit width and height so deferred images reserve their space and do not cause layout shift when they arrive. And do a quick mental fold test: if the image is visible without scrolling, it is not a lazy-load candidate, whatever the audit lists.

When to lazy-load and when not to

How to detect it

1. PageSpeed Insights: run the URL and open the "Defer offscreen images" opportunity, which lists each offending image and the estimated bytes and time saved.
2. Lighthouse: the same audit in Chrome DevTools under Performance, useful against staging before you ship a template change.
3. curl: pull the HTML and check which <img> tags carry the attribute:

   curl -s -A 'Mozilla/5.0' https://example.com/ 
     | grep -oiE '<img[^>]*>' | grep -civ 'loading=.lazy'

   A high count of images with no lazy attribute is your worklist.

4. DevTools Network panel: reload with the viewport at the top and watch which images fetch immediately. Anything below the fold that loads before you scroll is a candidate.

How to fix it

Add loading="lazy" to every below-the-fold <img> and <iframe>, and explicitly leave it off the hero and anything visible on load. On WordPress, native lazy loading is on by default for content images, so the usual fix is confirming your hero or featured image is excluded rather than adding the attribute everywhere. Pair the change with explicit dimensions to avoid layout shift, and verify LCP did not regress, over-eager lazy-loading of the main image is the single most common way this "fix" backfires. For the wider picture see lazy loading defined, the deeper SEO considerations, and how to improve LCP so you know which image never to defer.

FAQ

Will lazy-loading images hurt my SEO or indexing?

No, when done with native loading="lazy". Google renders pages and handles native lazy loading fine. The old risk came from JavaScript lazy-load libraries that hid images behind events Googlebot did not trigger. Native attribute, no problem.

Should I lazy-load my hero image?

Never. The hero is almost always your LCP element, and deferring it delays the exact paint the metric measures. Load it eagerly and consider fetchpriority="high" to pull it forward.

Do I still need a JavaScript lazy-load library?

For images and iframes, no, native loading="lazy" is supported across current browsers and is simpler and safer. Reserve JS approaches for background images or edge cases the native attribute does not cover.

Why did my page score drop after adding lazy loading?

You almost certainly lazy-loaded something above the fold, usually the LCP image. Remove the attribute from anything visible on load and the score recovers. Lazy loading helps only below the fold.

Does lazy loading cause layout shift?

Only if you omit dimensions. Set width and height (or a CSS aspect ratio) on every image so the browser reserves the space, and deferred images slot in without shifting content.

How do I decide where the fold is?

There is no fixed pixel line, the fold moves with screen size, so judge by the most common mobile viewport rather than your desktop. A safe rule of thumb: treat the first screen of content as eager and everything past it as lazy, then confirm in DevTools that your LCP element was not deferred. When in doubt, err toward loading one extra image eagerly rather than risking the paint that matters.