Lazy Loading

What is lazy loading?

Lazy loading is a way to delay loading non-critical resources until they are close to being needed—usually when an image, iframe, video, or embed is near the viewport instead of on the initial page load.

I like lazy loading, but I do not trust blanket implementations anymore. A few years ago, I treated it like free performance: add lazy loading to everything offscreen, celebrate the lower initial page weight, move on. Then I spent an afternoon debugging a product template for a Shopify store we worked with where the homepage hero image—the thing taking up most of the screen—had been marked loading="lazy" by an over-helpful app. LCP got worse, not better. Rankings did not crash overnight, but the page felt slower in the way users actually notice.

That was the moment I revised my mental model. Lazy loading is not a universal speed win. It is a prioritization tool. Used carefully, it helps the browser spend its early attention on what matters first. Used carelessly, it delays the exact assets you needed immediately.

For SEO, that distinction matters because lazy loading can touch three things at once: rendering, image discovery, and Core Web Vitals. Most teams I talk to focus only on the first one—fewer initial requests. Reasonable instinct. Incomplete instinct.

Why lazy loading matters for SEO

There are three practical SEO paths where lazy loading shows up.

1. It changes page performance

If a page has dozens of images, several embeds, and a long scroll depth, lazy loading can reduce the amount of work the browser does right away. Fewer requests. Less early bandwidth contention. More room for critical resources to load first.

That can help user-perceived speed and support Core Web Vitals like Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS)—but only if the deferred assets are actually non-critical. If your implementation delays the hero image, main product image, or some key iframe above the fold, you can sabotage the very metric you were trying to help.

Short version: lazy loading can improve performance by loading less upfront. Or hurt it by delaying the wrong thing. Both happen.

2. It changes what Google can reliably render

Googlebot can render JavaScript. I would never advise building on the assumption that Google cannot. But I also would not build on the assumption that Google will behave exactly like a fully interactive user in your most complicated front-end setup. Those are different claims. (Quick caveat: I am less worried about simple, standards-based implementations than custom event chains that require perfect timing.)

If content or image URLs only appear after custom scroll listeners, odd user interactions, fragile scripts, or late DOM mutations, indexing becomes less predictable. Not impossible—just less predictable. And “less predictable” is not where I want important content living.

3. It affects image SEO and search appearance

On ecommerce and editorial sites, images are not decorative side characters. They help pages rank, they appear in Google Images, and they often carry conversion weight. If your product imagery or article images are hidden behind a brittle lazy-loading setup, that can reduce discoverability or create weaker rendered pages.

I have seen this most often on category pages and recipe-style content where plugins apply the same lazy-loading rule to everything. Simple mistake. Expensive one.

Native lazy loading vs JavaScript lazy loading

There are two common ways to do this, and they are not equal in risk.

Native lazy loading

This is the browser-supported approach using attributes like:

<img src="example.jpg" loading="lazy" alt="Example image">

And for iframes:

<iframe src="https://www.youtube.com/embed/..." loading="lazy"></iframe>

Most of the time, this is where I start. It is simpler, easier to maintain, and usually less fragile than building your own system. If native lazy loading handles the use case, I rarely see a good SEO reason to make things more complicated.

JavaScript lazy loading

This usually relies on JavaScript—often the Intersection Observer API—to swap values like data-src into a real src when an element gets near the viewport.

That can work well. It also gives you more ways to break things. Late URL injection, missing fallbacks, placeholders that linger too long, libraries that wait for a scroll event that never fires in rendering, plugins that blindly touch every image on the page—this is where I see the messy failures. (I should mention—we tried automating audits for this pattern internally, and the weird edge cases were always custom JavaScript, not native loading.)

So my default recommendation is boring on purpose: if native lazy loading covers your needs, use it. Reach for JavaScript only when you need custom thresholds, advanced placeholders, legacy support, or some very deliberate UI behavior.

The biggest SEO risk: lazy loading the LCP image

If you remember only one thing from this page, remember this: do not lazy load the likely LCP image.

On many templates, that image is obvious. Homepage hero. Main product image. Featured article image. Category banner. If it is large, visible early, and likely to become the main visual element in the first viewport, the browser should discover it immediately and start fetching it early.

I used to think loading="lazy" on above-the-fold media was only a “small tradeoff.” After enough audits, I stopped believing that. It is often a direct own goal.

Google’s broader guidance on LCP optimization points in the same direction: help the browser discover and prioritize the important resource quickly. That is where fetchpriority="high" can help for the right image. Not every image. The right one.

A safer pattern looks like this:

• Do not lazy load above-the-fold hero images
• Use normal src and srcset
• Consider fetchpriority="high" for the likely LCP image
• Set explicit width and height
• Compress and size the image correctly

Example:

<img
  src="hero.jpg"
  srcset="hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="100vw"
  alt="Main product image"
  fetchpriority="high"
  width="1600"
  height="900">

Small distinction, big impact.

What should be lazy loaded?

Usually good candidates:

• Article images far below the fold
• Product gallery thumbnails not immediately visible
• Embedded videos
• Third-party widgets
• Maps and social embeds
• Offscreen iframes
• Long category-page media blocks

Usually poor candidates:

• Hero images
• Main product images above the fold
• Logos or visual assets needed for first paint
• Critical CSS or fonts
• Primary navigation assets
• Anything likely to become the LCP element

The template decides a lot here. A text-heavy blog post and a media-heavy category page should not be treated the same way. (Edit, mid-thought—actually, even two ecommerce templates on the same site often need different treatment.)

Decision tree: should you lazy load this asset?

1. Is the asset visible above the fold on common devices?
   If yes, do not lazy load it.
2. Could it become the LCP element?
   If yes, load it normally and consider fetchpriority="high".
3. Is it an offscreen image, iframe, video, or third-party embed?
   If yes, it is usually a good lazy-loading candidate.
4. Does the implementation require custom JavaScript to reveal the real URL?
   If yes, ask whether native lazy loading can replace it.
5. Will Google still be able to discover the resource in rendered HTML?
   If no, rethink the setup.
6. Is the page small and media-light?
   If yes, the complexity may not be worth it.

How Googlebot sees lazy-loaded content

Google Search Central has been fairly consistent here: lazy-loaded content can work, but it should use supported patterns and remain accessible to Google.

In practice, I check a few simple things:

• Is the real image URL visible in rendered HTML?
• Does the resource load when it approaches the viewport, rather than after some odd user action?
• Does the page degrade reasonably if JavaScript misbehaves?
• Are the image URLs blocked by robots.txt or hidden in a way that makes discovery fragile?

I do not need every implementation to be elegant. I need it to be reliable. That is a different standard—and a better one for SEO.

Real-world example

On an ecommerce collection page we reviewed, the client had installed a performance plugin that applied lazy loading to nearly every image by default. The theory sounded good. The category banner, the first row of product images, and even the main promotional tile were being deferred.

In DevTools, the waterfall told the story fast: placeholder assets loaded early, the main visible images started later than they should have, and the first viewport looked busy but incomplete for too long. In Search Console’s URL Inspection render, the page still appeared, so this was not a hard indexing failure. It was subtler than that. Poor prioritization.

We removed lazy loading from the above-the-fold images, kept it on lower product rows and embeds, added explicit dimensions, and cleaned up image sizing. The result was not magical. It was sane. The page felt faster, LCP improved, and the implementation got simpler—which is usually a good sign…

How to test lazy loading for SEO

Use Google Search Console

Inspect the URL and compare the crawled HTML, rendered result, resources, and indexing behavior. If important imagery is missing or delayed in the rendered version, your setup deserves scrutiny.

Use Lighthouse or PageSpeed Insights

These are useful for spotting whether offscreen images are deferred and whether your likely LCP image is being discovered late. If the main visual element is lazy loaded and LCP is weak, that is one of the first things I would fix.

Use Screaming Frog with JavaScript rendering

Screaming Frog SEO Spider is good for comparing raw HTML with rendered HTML and seeing which assets only appear after execution. I use this a lot when a site has custom image components or framework-heavy rendering.

Use browser DevTools

Check the Network panel and waterfall:

• Does the hero image start loading immediately?
• Are offscreen images deferred?
• Are placeholders hanging around too long?
• Are third-party embeds consuming bandwidth too early?

Best practices for lazy loading

1. Use native lazy loading where possible. Simpler is usually safer.
2. Do not lazy load likely LCP images. This is the rule I care about most.
3. Prioritize key resources. Use fetchpriority="high" selectively.
4. Keep image URLs discoverable. Google should be able to access the real resource.
5. Set dimensions. Reduce layout instability.
6. Use responsive images. srcset and sizes still matter.
7. Test with rendered tools. Search Console, Lighthouse, Screaming Frog, DevTools.
8. Be suspicious of blanket plugin rules. Convenience often hides bad prioritization.

Lazy loading and image optimization are not the same thing

This confusion comes up constantly. Lazy loading changes when a resource is fetched. It does not reduce file size on its own.

You still need image optimization basics:

• Modern formats like WebP or AVIF when appropriate
• Correct dimensions
• Compression
• Responsive delivery
• CDN caching where relevant

A site can lazy load perfectly and still be slow because every image is oversized. It can also optimize every file and still waste early network requests by loading too much above the fold. You want both sides working together.

Common mistakes

• Lazy loading the hero image or likely LCP element
• Applying a plugin or CMS setting to every image without template review
• Relying on custom scroll events instead of supported patterns
• Hiding real image URLs too late in JavaScript
• Forgetting width and height, which creates CLS issues
• Assuming lazy loading replaces compression and responsive images
• Never validating rendered output in Search Console or Screaming Frog

Self-check

• Is my above-the-fold hero image loading normally?
• Could any lazy-loaded asset become the LCP element?
• Are offscreen images, iframes, and embeds the main things being deferred?
• Can Google see the real resources in rendered HTML?
• Have I checked the waterfall in DevTools?
• Have I verified behavior in Google Search Console and Screaming Frog JavaScript rendering?
• Did I optimize file size separately from lazy loading?

FAQ

Does lazy loading help SEO?

It can. When it defers non-critical offscreen resources, it often improves efficiency and user experience. When it delays critical assets, it can hurt performance and weaken SEO outcomes.

Is native lazy loading better than JavaScript lazy loading?

Usually, yes. Native lazy loading is simpler and less fragile. JavaScript can be fine, but it introduces more failure points.

Should I lazy load all images?

No. I would avoid lazy loading any image that is above the fold or likely to become the LCP element.

Can lazy loading hurt LCP?

Yes. This is one of the most common problems I see. If the browser discovers the main image too late, LCP suffers.

Can Google index lazy-loaded images?

Yes, if they are implemented in a way Google can render and discover reliably. Problems usually appear when URLs are hidden behind fragile scripts or unusual interactions.

Should I use fetchpriority="high" with lazy loading?

Not on the same image. fetchpriority="high" is typically for important images that should load early, while lazy loading is for assets that can wait.

Does lazy loading replace image compression?

No. It only changes timing. Compression, sizing, formats, and responsive delivery still matter.

What pages benefit most from lazy loading?

Pages with long scroll depth and lots of media—category pages, editorial pages with many images, galleries, recipe pages, and pages with heavy embeds—usually benefit the most.

Bottom line

Lazy loading helps SEO when it protects priority. That is the whole game.

Defer offscreen media, embeds, and non-critical assets. Do not defer the content users see first. Especially the likely LCP image. If you build around that principle—and verify it in Google Search Console, Lighthouse, Screaming Frog JavaScript rendering, and DevTools—you avoid most of the damage I see from “performance optimizations” that looked smart in a plugin dashboard and awful in the waterfall.