Lazy Loading Images: The Setting That Helps Most Pages and Hurts One

Lazy loading delays downloading an image until a visitor actually scrolls close enough to see it, instead of the browser downloading every image on the page the moment it loads, whether the visitor ever scrolls that far or not. For a long page with a dozen images stacked below the fold, that's a genuinely free performance win: nothing changes for a visitor who scrolls the whole page, and a visitor who reads the first paragraph and leaves never pays the download cost for images they never saw.

How to Turn It On

Modern browsers support lazy loading natively, no library or script required:

<img src="product-photo.jpg" loading="lazy" alt="...">

That single attribute is enough for any current browser. Older approaches used JavaScript libraries (like lazysizes) to fake the same behaviour before native support existed; if a site is still running one of those for browser-compatibility reasons that no longer apply, it's worth checking whether the native attribute alone now covers it, since the JS library itself has a download and execution cost the native attribute doesn't.

The Mistake: Lazy-Loading the Image Visible on Load

Here's where it goes wrong. Some sites, or some page-speed plugins configured too aggressively, apply loading="lazy" to every image on the page, including the hero image sitting in the very first thing a visitor sees.

That's backwards. loading="lazy" tells the browser "don't bother downloading this until it's needed." For an image that's already visible the instant the page renders, it's needed immediately, so telling the browser to delay it means the browser waits, then starts downloading, then waits again for that download to finish, all before the visitor sees the image that was supposed to be there from the start.

This usually shows up directly in Core Web Vitals as a worse LCP (Largest Contentful Paint), since the hero image is very often the LCP element on a marketing or product page. Lazy-loading it doesn't make the page faster overall, it just moves the wait from "invisible, below the fold" to "the exact thing the visitor is staring at while it loads."

The Fix: Lazy-Load Below the Fold, Not Above It

The rule is simple once it's stated plainly:

• Above the fold (visible without scrolling, on load): never lazy-load. If it's your likely LCP element, actively help the browser prioritise it with fetchpriority="high" instead.
• Below the fold (only visible after scrolling): lazy-load everything you reasonably can.

<!-- Hero image: visible immediately, help it load fast -->
<img src="hero.jpg" fetchpriority="high" alt="...">

<!-- Image further down the page: fine to delay -->
<img src="gallery-photo-4.jpg" loading="lazy" alt="...">

Most page-builder and CMS lazy-load settings apply globally by default, on or off for the whole site, rather than being smart about what's above versus below the fold on any given template. That's exactly how the mistake spreads: a well-intentioned "improve page speed" toggle quietly working against the one image that most affects the site's Core Web Vitals score.

How to Check Whether You Have This

1. Open the page in an incognito browser window and view the page source (or use the browser inspector).
2. Find the first image that renders without scrolling, usually a hero photo or banner.
3. Check whether it carries a loading="lazy" attribute. If it does, that's the fix: remove it (or add fetchpriority="high" instead) for that specific image, while leaving lazy loading in place further down the page.

PageSpeed Insights and Lighthouse will also flag this directly, usually as guidance about the LCP element being delayed by lazy-loading, if you'd rather have a tool point at the exact image than check by hand.

The Fast Way to Check Yours

Working out which images should and shouldn't be lazy-loaded, on a page you didn't build yourself, is exactly the kind of check that benefits from automation rather than a manual once-over. AuditCrow's free scan looks at the speed fundamentals that affect Core Web Vitals, including oversized assets covered in how large, uncompressed images destroy page speed, alongside the rest of a page's technical health.