Defer Offscreen Images: Lazy-Loading Done Right

What this means

When a browser loads a page, it tries to download every image it finds in the HTML, whether that image is visible on screen or buried three screens down. Images far below the fold are not needed for the first paint, yet they still consume bandwidth and connections at the worst possible moment: while the visitor is waiting for the top of the page to render.

"Deferring" an offscreen image simply means telling the browser to wait. Instead of fetching the image up front, the browser holds off until the visitor scrolls close to it. This is what "lazy loading" does. For a full picture of how images fit into your wider optimisation work, see our complete image SEO guide.

Why it matters

Loading offscreen images upfront wastes bandwidth and ties up the limited number of connections the browser can make. Every byte spent on an image nobody can see yet is a byte not spent on the hero image, the headline, or the main content. That delay pushes back your Largest Contentful Paint (LCP), one of Google's Core Web Vitals and a confirmed ranking signal.

On image-heavy pages the gains are real: deferring offscreen images frees up the network so the critical above-the-fold content arrives sooner. The flip side, covered below, is that getting lazy loading wrong on the wrong image can make LCP worse, so the technique has to be applied with care. Learn how this connects to the wider metric in our LCP complete guide.

How it gets flagged

Lighthouse (the engine behind PageSpeed Insights and the audit in this tool) raises "Defer offscreen images" when an image meets all of these conditions:

• The image renders below the fold, ending past roughly three times the viewport height.
• It has no lazy-loading attribute, so the browser fetches it immediately.
• Deferring it would save a meaningful amount of data or load time on the network.

The audit reports the wasted bytes per image so you can prioritise the largest offenders first.

How to fix it

For most sites the fix is a single attribute. Native browser lazy loading is supported by every major browser (around 95 percent of users globally), needs no JavaScript, and is the recommended first choice. Add loading="lazy" to each below-the-fold image:

<!-- Below the fold: defer it -->
<img src="/gallery/photo-08.jpg" alt="Studio session"
     width="1200" height="800" loading="lazy">

<!-- Above the fold / LCP image: load it eagerly, boost priority -->
<img src="/hero.jpg" alt="Main banner"
     width="1600" height="900"
     loading="eager" fetchpriority="high">

Always set explicit width and height so the browser reserves space and you do not trade an image problem for a layout-shift problem. See our CLS complete guide for why this matters.

For complex cases, such as background images set in CSS, carousels, or framework components, the native attribute does not apply. Use the JavaScript IntersectionObserver API to watch when an element approaches the viewport and swap in the real source only then. Most modern CMS platforms and image plugins already ship this behaviour, so check your settings before writing custom code.

False positives

Not every flag needs action. Common false positives include:

• Images that are already lazy-loaded. Older Lighthouse versions sometimes still listed images that carried loading="lazy". Confirm the attribute is present in the rendered HTML and move on.
• JavaScript-deferred images. If a script already swaps the source on scroll, the audit may not detect it. Verify in the Network tab that the image truly loads late.
• Tiny or above-the-fold images mislabelled. An image counted as offscreen that is actually visible on smaller breakpoints should stay eager.

When in doubt, trust the rendered behaviour over the audit label and protect your LCP element first.

FAQ