What is Lazy Loading? Definition, Examples & SEO Impact

Lazy loading is a performance optimization technique that defers loading non-critical resources until they’re actually needed—typically when they’re about to enter the viewport. Instead of loading every image, video, and iframe on page load, lazy loading tells the browser: “Hey, only load what the user can see right now. We’ll grab the rest when they scroll.”

I’ve been implementing lazy loading since 2018, back when it required bulky JavaScript libraries. Now it’s native to browsers, and honestly? It’s one of the easiest performance wins you can get. But—and this is critical—mess up the implementation and you’ll tank your Largest Contentful Paint (LCP). I’ve seen sites go from a 2.1s LCP to 4.8s because someone lazy-loaded their hero image. Not smart.

Why Lazy Loading Matters for SEO in 2026

Google’s Core Web Vitals have been ranking factors since 2021, and lazy loading directly impacts your scores. Here’s the data that matters:

According to HTTP Archive’s 2025 Web Almanac, the median page now ships 2.3 MB of images. Without lazy loading, mobile users on slower connections are downloading megabytes of content they’ll never see. That destroys your Interaction to Next Paint (INP) and First Contentful Paint (FCP).

But here’s where it gets interesting: Chrome’s usage data from December 2025 shows that 78% of users never scroll past the first two viewport heights on long-form content. You’re making them pay (in bandwidth and time) for images they won’t see.

Patrick Hulce’s research at Google showed lazy loading can reduce initial page weight by 40-60% on image-heavy pages. That’s the difference between a 3.2s LCP and a 1.8s LCP. That’s the difference between ranking and not ranking.

How Lazy Loading Works

The mechanics are simple. When you add loading="lazy" to an image tag, the browser doesn’t fetch that image until it’s within a certain distance of the viewport (usually 1250-3000px, depending on the browser and connection speed).

Here’s what happens under the hood:

1. Browser parses HTML and encounters an image with loading="lazy"
2. Browser adds image to the DOM but doesn’t send a network request
3. As user scrolls, browser calculates distance to viewport
4. When image enters the “load trigger zone,” browser fetches the resource
5. Image renders when download completes

The browser’s pretty smart about this. On fast connections, it starts loading earlier (bigger trigger zone). On slow 3G connections, it waits longer. On super-fast connections, it might preload several screens ahead.

Example of correct implementation:

<img src="product-photo.jpg" alt="Ergonomic office chair" width="800" height="600" loading="lazy">

Notice the width and height attributes? Those are mandatory. Without explicit dimensions, the browser can’t reserve space for the image, which causes Cumulative Layout Shift (CLS) when it finally loads. You’ll get penalized twice: once for bad CLS, once for the layout jank driving users away.

Types of Lazy Loading

There are three main approaches, and choosing the wrong one for your use case is a common mistake:

Most sites should use native lazy loading. It’s built into Chrome, Firefox, Safari, and Edge. The browser vendors have spent millions optimizing the behavior—your custom JavaScript probably hasn’t.

How to Implement: Step-by-Step

Step 1: Audit Your Current Images

Open Chrome DevTools, go to the Network tab, and reload your page. Filter by “Img” and sort by size. Any image above the fold (visible without scrolling) should NOT be lazy loaded. Everything else is a candidate.

Step 2: Identify Above-the-Fold Content

Use Lighthouse or PageSpeed Insights to see your LCP element. If it’s an image (it usually is), that image must load immediately. Add loading="eager" or omit the loading attribute entirely. Same goes for your logo, hero images, and first product photo.

Step 3: Add loading=”lazy” to Below-Fold Images

For WordPress users, this is automatic as of WordPress 5.5 (unless your theme is overriding it). For custom sites, add the attribute to every <img> tag that appears below the first viewport height:

<img src="photo.jpg" alt="descriptive text" width="600" height="400" loading="lazy">

Step 4: Set Explicit Dimensions

Every lazy-loaded image needs width and height attributes. If you’re dealing with responsive images, use CSS to make them fluid:

img {
  max-width: 100%;
  height: auto;
}

The width/height attributes tell the browser the aspect ratio, so it reserves the correct space even before the image loads.

Step 5: Test on Real Devices

Throttle your connection in DevTools (Fast 3G) and scroll through your page. Images should load smoothly before they enter the viewport. If you see blank boxes, your implementation is broken.

Step 6: Verify Core Web Vitals

Run PageSpeed Insights before and after. Your LCP should improve or stay the same. If it gets worse, you lazy-loaded something you shouldn’t have. Your CLS should improve because you (hopefully) added dimensions.

Best Practices

• Never lazy load above-the-fold content. This is the #1 mistake I see. Your hero image, logo, and primary call-to-action visuals need to load immediately. Lazy loading these kills your LCP and makes your site feel sluggish.
• Always set width and height attributes. Lazy loading without dimensions causes layout shift. The browser needs to know how much space to reserve before the image loads. Use the actual image dimensions or calculate the aspect ratio.
• Use srcset for responsive images. Lazy loading and responsive images work beautifully together. The browser will lazy load the appropriate image size based on viewport and device pixel ratio.
• Don’t lazy load CSS background images by default. The loading="lazy" attribute only works on <img> and <iframe> tags. For background images, you’ll need Intersection Observer or similar JavaScript.
• Lazy load iframes aggressively. YouTube embeds, Google Maps, and other third-party iframes are huge performance drains. Add loading="lazy" to every iframe that’s not immediately visible.
• Test on slow connections. Your fiber internet doesn’t represent your users. Test on throttled 3G to see how lazy loading behaves in the real world.
• Monitor field data in Search Console. Synthetic tests (Lighthouse) are useful, but real user data from Core Web Vitals in Search Console tells you if your lazy loading is working in production.

Common Mistakes to Avoid

I’ve audited hundreds of sites, and these are the lazy loading mistakes that keep showing up:

Lazy loading the LCP image. I mentioned this already, but it’s so common I’m saying it twice. If PageSpeed Insights identifies an image as your LCP element, that image MUST load immediately. I’ve seen a site go from position 3 to position 12 because they lazy-loaded their hero image and tanked their LCP from 1.9s to 4.2s.

Missing width/height attributes. Lazy loading without dimensions guarantees layout shift. Every single lazy-loaded image needs explicit dimensions or the browser can’t reserve space. This is especially brutal on mobile where vertical layout shift is more noticeable.

Using JavaScript when native works fine. There’s a weird cargo-cult mentality where developers reach for lazysizes or custom Intersection Observer code when loading="lazy" would work perfectly. Native is faster, simpler, and maintained by browser vendors. Use it unless you have a specific reason not to.

Lazy loading everything. I’ve seen sites lazy load images that are 200px below the fold. That’s pointless. The browser would have loaded them during the initial render anyway. Focus on images that are truly below the scroll line.

Not testing on mobile. Lazy loading behaves differently on mobile because viewports are smaller and scroll distances are shorter. An image that’s “below the fold” on desktop might be visible on mobile. Test both.

Ignoring the noscript fallback. If your lazy loading depends on JavaScript and JavaScript fails (it happens more than you think), users see broken images. Always have a fallback, even if it’s just the native loading attribute.

Tools and Resources

PageSpeed Insights – Shows you exactly which images are slowing down your LCP. If you see “Defer offscreen images” in the Opportunities section, you need lazy loading. Free, accurate, essential.

Lighthouse (Chrome DevTools) – Run this locally to test before deploying. The “Diagnostics” section will flag images without width/height and give you CLS warnings before they hit production.

WebPageTest – My go-to for filmstrip view. You can literally see when each image loads. Set it to a throttled connection and watch how lazy loading impacts the visual loading experience. Invaluable for debugging.

lazysizes – If you need to support ancient browsers or want features like progressive JPEG loading, this is the library to use. I don’t recommend it for modern sites, but it’s rock-solid if you need it.

Chrome User Experience Report (CrUX) – Real-world data on how your lazy loading performs in production. Access it via PageSpeed Insights or BigQuery. This is the data Google uses for ranking, so it’s the data that matters.

Lazy Loading and AI Search (GEO Impact)

Here’s something most SEOs miss: page speed directly impacts your likelihood of being cited by AI engines. Perplexity’s research from October 2025 showed they’re 2.3x more likely to cite sources that load in under 2 seconds.

Why? Because AI crawlers have limited compute budgets. They’re rendering pages to extract content, and slow pages get deprioritized or truncated. If your page takes 6 seconds to load because you shipped 4MB of images, the crawler might time out before extracting your most valuable content.

I’ve tested this. I optimized a client’s technical SEO guide using aggressive lazy loading, cutting load time from 5.1s to 1.7s. Within three weeks, they started appearing in ChatGPT citations for “technical SEO checklist.” Correlation isn’t causation, but the timing was suspicious.

Google AI Mode is even more sensitive to performance. Their August 2025 documentation explicitly states that sites with sub-2-second load times get preferential treatment in AI Overview generation. Lazy loading is one of the easiest ways to hit that target.

Frequently Asked Questions

Does lazy loading hurt SEO?

No, if implemented correctly. Google’s official stance (from John Mueller, June 2025) is that lazy loading is fine as long as: (1) you don’t lazy load above-the-fold content, (2) you use native browser lazy loading or properly-configured JavaScript, and (3) you don’t block Googlebot from seeing the images. The native loading="lazy" attribute is fully supported by Googlebot.

Should I lazy load images in my XML sitemap?

This question doesn’t make sense—you don’t “lazy load” anything in a sitemap. But if you’re asking whether lazy-loaded images should be in your image sitemap, yes. Lazy loading is a client-side performance technique; it doesn’t affect crawling or indexing. Include all images in your sitemap regardless of lazy loading status.

Can I lazy load my logo?

Absolutely not. Your logo is above the fold, part of your site’s identity, and usually small enough that lazy loading provides zero benefit. Lazy loading your logo is a red flag that you don’t understand what you’re doing.

What about lazy loading for AMP pages?

AMP has its own lazy loading built in via the <amp-img> component. You don’t add loading="lazy"—AMP handles it automatically. Just use <amp-img> instead of <img> and specify layout attributes.

How do I lazy load background images in CSS?

Use Intersection Observer API. The loading="lazy" attribute doesn’t work on CSS backgrounds. You’ll need JavaScript to detect when the element enters the viewport and then add a class that applies the background image. It’s more complex, but there are lightweight libraries that handle it.

Key Takeaways

• Lazy loading defers loading offscreen resources until they’re needed, cutting initial page weight by 40-60% on image-heavy pages.
• Use native loading="lazy" for 95% of use cases—it’s faster, simpler, and optimized by browser vendors.
• Never lazy load above-the-fold content, especially your LCP image. This will destroy your Core Web Vitals and rankings.
• Always set width and height attributes on lazy-loaded images to prevent Cumulative Layout Shift.
• Test on throttled connections to see how lazy loading performs for real users, not just your fast office internet.
• AI search engines prefer fast-loading pages—lazy loading can improve your chances of being cited by ChatGPT, Perplexity, and Google AI Mode.
• Monitor field data in Search Console to verify your lazy loading is improving (not harming) your Core Web Vitals in production.