What Is Lazy Loading? When It Helps and When It Hurts

Jul 16, 2026 · SEO Glossary

Somewhere along the way, "lazy load your images" hardened into dogma, and now I regularly audit sites that lazy-load everything — including the giant hero image at the top of the page. That's like putting your front door key at the bottom of a locked box. The technique isn't the problem; the blanket application is.

Let's define it properly. What is lazy loading? It's a technique where the browser defers loading a resource — usually an image or iframe — until it's actually needed, typically when the user scrolls near it. Instead of downloading all forty product images the moment the page opens, the browser fetches the six that are visible and grabs the rest on demand.

What Is Lazy Loading Solving?

Waste, mostly. On a typical long page, users never scroll past the first few screens. Loading every image up front burns bandwidth on mobile plans, delays the resources that are visible, and makes your server do work nobody benefits from. Deferring below-the-fold assets means:

• The initial page load competes with fewer downloads, so visible content renders sooner.
• Users on metered connections don't pay for images they never see.
• Your server and CDN handle meaningfully less traffic on long pages — on image-heavy category pages, I've seen initial payload drop 60–70%.

Native Lazy Loading vs. JavaScript Libraries

Years ago you needed a JavaScript library watching scroll position. Now the browser does it natively with one attribute:

<img src="product-photo.webp" loading="lazy" alt="Blue ceramic mug" width="600" height="600">

Every modern browser supports this for images and iframes. Unless you need very custom behavior (fancy blur-up placeholders, precise loading distances), the native attribute should be your default — it's zero dependencies, it works with JavaScript disabled, and the browser tunes the load-ahead distance based on connection speed.

Old JavaScript solutions had a nasty SEO side effect worth remembering: they put the real image URL in a data-src attribute and left src empty or pointing to a placeholder. If the script relied on scroll events, Googlebot — which doesn't scroll — sometimes never saw the real images. Modern libraries use IntersectionObserver, which Google's renderer handles fine, but if your site still runs a lazy-load plugin from 2016, that's worth checking today.

The Mistake That Wrecks Your LCP

Here's the big one. Your hero image — the largest thing in the viewport — is almost certainly your Largest Contentful Paint element. Lazy-loading it tells the browser "this isn't urgent," so the browser deprioritizes the single most urgent asset on the page. Measured impact in the wild is routinely 0.5 to 1+ seconds of added LCP. I've watched a site go from failing to passing Core Web Vitals by deleting one attribute.

The rule is short enough to memorize:

Above the fold: load eagerly, consider fetchpriority="high". Below the fold: lazy-load freely.

The usual culprit isn't a developer decision, it's a CMS plugin or theme that stamps loading="lazy" onto every image tag it renders, hero included. WordPress did exactly this for a while before adding logic to skip the first images on a page.

Beyond Images: What Else Can Wait

• Iframes. Embedded maps and videos are some of the heaviest things on any page. loading="lazy" on an iframe, or the "facade" pattern (show a thumbnail, load the real embed on click), can save literal megabytes. A YouTube embed alone pulls ~500 KB–1 MB of JavaScript before anyone presses play.
• Non-critical JavaScript. Chat widgets, review carousels, and analytics extras can initialize after the main content is interactive.
• Comment sections. Loading 300 comments on page load helps no one; load them on scroll or on click.

Edge Cases That Bite

Images just below the fold. "The fold" is different on every device. An image that's below the fold on desktop may be the LCP element on a tall phone screen. When in doubt, eagerly load the first image or two of any page regardless of assumed position.

Missing dimensions. Lazy-loaded images without width and height attributes cause layout shift when they pop in — you fix one metric and break another. Always reserve the space.

Infinite scroll. Lazy-loading content (not just images) via infinite scroll needs paginated URLs underneath, or crawlers will only ever see page one of your product catalog.

CSS background images. The loading attribute only exists on <img> and <iframe> elements. A background set in CSS loads whenever its rule applies, so a huge background hero can't be deferred this way — either convert it to a real <img> positioned with CSS, or accept that it loads eagerly and put the optimization effort into its file size instead.

How to Check Your Own Site

Open your key templates and look at the first image's HTML — if it says loading="lazy", you've found a problem worth five minutes of anyone's time. Then check the opposite failure: pages loading 5+ MB of images up front because nothing is deferred. A full-site crawl makes this practical at scale, flagging oversized images and slow pages across every template rather than the three URLs you thought to test by hand. In my experience the same template bug repeats across thousands of pages, which is bad news and good news: one fix, sitewide payoff.