Lazy Loading Best Practices: SEO-Safe Implementation for Images and Resources

By Guy Sheetrit, CEO of Over The Top SEO

What Is Lazy Loading and Why It Matters for SEO

Lazy loading is a web performance technique that defers the loading of non-critical resources — primarily images and iframes — until they are about to enter the user’s viewport. Instead of loading every image on a page at initial page load, lazy loading loads only what the user can actually see, fetching additional resources as they scroll. The result is faster initial page loads, lower bandwidth consumption, and improved Core Web Vitals scores — all of which have direct SEO implications.

The SEO connection is straightforward: Google uses Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — as ranking signals. Lazy loading affects all three. When implemented correctly, it dramatically improves LCP by reducing the initial payload the browser must load before rendering the above-the-fold content. When implemented incorrectly, it causes LCP to worsen (by lazy loading the hero image that is actually the LCP element), introduces CLS (by reserving insufficient space for lazy-loaded images), and can break Google’s ability to crawl and index images throughout your site.

The challenge is that lazy loading is frequently implemented without SEO consideration — developers apply it broadly to reduce page weight without understanding which images should never be lazy loaded, how to preserve CLS scores during implementation, and how Googlebot interacts with JavaScript-triggered lazy loading. This guide covers the complete technical picture: when lazy loading helps, when it hurts, and how to implement it in ways that improve both performance and search visibility. Our technical SEO team audits lazy loading implementation as a standard component of Core Web Vitals optimization engagements.

The HTML Native Lazy Loading Standard

The simplest and most SEO-safe lazy loading implementation uses the HTML loading="lazy" attribute, now supported by all major browsers. Adding this attribute to an <img> or <iframe> tag instructs the browser to defer loading until the element is near the viewport:

<img src="product-photo.jpg" alt="Product description" loading="lazy" width="800" height="600">

Native lazy loading has important advantages over JavaScript-based implementations: it requires no JavaScript library, no IntersectionObserver code, and no additional dependencies. Critically, it’s also more Googlebot-compatible — Google’s crawler supports the loading="lazy" attribute and will crawl images that use it, unlike some JavaScript-based lazy loading implementations that Googlebot cannot execute.

The width and height attributes shown above are non-optional for SEO purposes. They allow the browser to calculate the correct aspect ratio and reserve the appropriate space in the layout before the image loads — preventing the CLS that occurs when images load and push surrounding content down. Without explicit dimensions, lazy loading will cause CLS, damaging your Core Web Vitals score even as it improves load time.

Browser support: Chrome 76+, Firefox 75+, Edge 79+, Safari 15.4+. For older browsers, native lazy loading degrades gracefully — the browser simply loads images normally as if the attribute weren’t present. No polyfill is needed; older browsers will load all images, which is safe for SEO.

The Critical Rule: Never Lazy Load Your LCP Image

The single most impactful SEO rule for lazy loading is this: never apply loading="lazy" to your Largest Contentful Paint (LCP) element. This mistake is extremely common — developers apply lazy loading to all images on a page, including the hero image or banner that is typically the largest above-the-fold element and therefore the LCP element. The result is a dramatically worsened LCP score, directly hurting ranking potential.

The LCP element is the largest image or text block visible in the viewport on initial load. For most marketing and content pages, this is the hero image, the featured article image, or a large product photo positioned above the fold. Lazy loading this image tells the browser to delay loading it until needed — but since it’s already visible on initial load, “when needed” should be immediately. The lazy loading instruction creates artificial delay on an element the browser would have loaded immediately anyway, adding 200-500ms or more to LCP depending on network conditions.

How to identify your LCP element: open Chrome DevTools, run a Lighthouse audit, and check the “Largest Contentful Paint element” section. Alternatively, use the PageSpeed Insights API or Google Search Console’s Core Web Vitals report. Once identified, ensure that element’s <img> tag uses loading="eager" (the default behavior) or has no loading attribute at all. If you’re using a blanket lazy loading implementation via JavaScript that applies to all images, explicitly exclude the LCP image.

The correct implementation pattern:

<!-- Hero/LCP image: NEVER lazy load -->
<img src="hero.jpg" alt="Hero description" loading="eager" width="1200" height="630" fetchpriority="high">

<!-- Below-fold images: lazy load these -->
<img src="content-image.jpg" alt="Content description" loading="lazy" width="800" height="450">

The fetchpriority="high" attribute on the LCP image is an additional optimization that instructs the browser to prioritize fetching this resource ahead of other resources in the download queue — often reducing LCP by an additional 100-300ms.

JavaScript Lazy Loading: When and How to Use It

Before native loading="lazy" browser support was universal, JavaScript-based lazy loading via IntersectionObserver was the standard approach. Many sites still use JavaScript lazy loading libraries — lazysizes, lozad.js, vanilla-lazyload, and various CMS plugin implementations. Understanding the SEO implications of JavaScript lazy loading is essential for auditing existing implementations.

The core SEO risk with JavaScript lazy loading is Googlebot compatibility. Googlebot can execute JavaScript, but does so with significant limitations: it renders pages in a second wave of processing that may occur hours or days after initial crawl, it has a crawl budget that limits how much JavaScript rendering it performs per site, and it may not execute JavaScript-based lazy loading correctly on all pages. Images that depend on JavaScript to load may not be discoverable or indexable by Googlebot even if they’re perfectly visible to human users.

Google’s official guidance is that native loading="lazy" is preferred over JavaScript lazy loading for SEO because it doesn’t have these rendering dependencies. If you’re using JavaScript lazy loading, verify Googlebot can see your images by: using Google Search Console’s URL Inspection tool to fetch a page and check “Page screenshot” in the rendered view, checking whether your images appear in Google image search, and running a server-side rendering audit to confirm image src attributes aren’t hidden behind JavaScript execution.

If you must use JavaScript lazy loading (for browser compatibility with older IE versions, or for specific implementation requirements), use the data-src pattern with proper fallback noscript tags:

<img data-src="image.jpg" alt="Description" class="lazyload" width="800" height="450">
<noscript><img src="image.jpg" alt="Description" width="800" height="450"></noscript>

The <noscript> fallback ensures Googlebot, which may process pages in no-JavaScript mode during first-pass crawling, can still discover and index the image.

Lazy Loading for iFrames and Videos

Lazy loading iframes — used for embedded YouTube videos, Google Maps, social media embeds, and third-party widgets — can produce dramatic performance improvements because iframes typically load substantial third-party JavaScript that significantly inflates page weight. A page with three embedded YouTube videos that load eagerly may have 1-2MB of additional JavaScript loading before the user has scrolled to see any of those videos.

Native iframe lazy loading using loading="lazy" is supported in Chrome and Edge but not Safari (as of 2026). For broad compatibility, a facade pattern is more effective: display a static thumbnail image in place of the iframe until the user interacts, then swap in the actual iframe on click or hover. For YouTube, this means displaying a static thumbnail with a play button overlay, then injecting the full <iframe> on click. This approach provides performance benefits in all browsers and is unambiguously SEO-safe since the page’s visible content (the thumbnail) is always present in the initial HTML.

Lite-YouTube-Embed is an open-source web component that implements this facade pattern for YouTube embeds with minimal code. For Google Maps, a static map image linked to Google Maps is a simpler alternative that eliminates map iframe JavaScript entirely for users who don’t need interactive maps.

For HTML5 video elements, use preload="none" to prevent automatic video preloading, and consider poster images to provide a visible placeholder that doesn’t require the video itself to load:

<video preload="none" poster="video-thumbnail.jpg" controls>
  <source src="video.mp4" type="video/mp4">
</video>

CMS-Specific Lazy Loading Considerations

Most CMS platforms have built-in lazy loading features or popular plugin implementations. Understanding how each CMS handles lazy loading — and where each creates SEO risks — is practical knowledge for auditing real-world sites.

WordPress: WordPress has applied loading="lazy" natively to all images since version 5.5 (2020). This is broadly positive but has a known issue: WordPress applies lazy loading to all images including those above the fold, occasionally including the LCP image. The WP Rocket and Perfmatters plugins offer more granular control, specifically the ability to exclude the LCP image from lazy loading. For theme-generated hero images set via CSS background-image (rather than <img> tags), native lazy loading doesn’t apply — you’ll need a different optimization approach (preload link tag in the document head).

Shopify: Shopify themes vary widely in lazy loading implementation. Dawn (the default theme) applies native lazy loading to product images but not the main product image visible above the fold. Custom themes may apply lazy loading inconsistently. Audit each template type (product, collection, homepage) separately since CMS templates often apply lazy loading at the template level without accounting for which images are above vs. below the fold in each layout.

Webflow: Webflow applies native lazy loading to images by default with appropriate LCP exclusions in recent versions. Check via URL Inspection that the LCP image on key page templates is not being lazy loaded.

Next.js / React: Next.js’s <Image> component applies lazy loading by default and includes native LCP optimization through its priority prop. Adding priority to the LCP image disables lazy loading for that element and adds a preload link tag — the correct technical implementation. React sites using standard <img> tags without the Next.js Image component should implement native lazy loading with manual LCP exclusion.

Lazy Loading Audit Checklist

Use this checklist to audit lazy loading implementation on any site:

• ✅ LCP element identified (via Lighthouse or PageSpeed Insights)
• ✅ LCP image uses loading="eager" or no loading attribute (never loading="lazy")
• ✅ LCP image has fetchpriority="high" attribute
• ✅ All below-fold images use loading="lazy" with explicit width and height attributes
• ✅ No CLS caused by lazy-loaded images (verify via Lighthouse CLS diagnostic)
• ✅ If using JavaScript lazy loading: noscript fallbacks present for Googlebot compatibility
• ✅ iFrame embeds use facade pattern or native lazy loading with appropriate fallbacks
• ✅ Video elements use preload="none" with poster images
• ✅ Google Search Console URL Inspection confirms lazy-loaded images are visible in rendered page screenshots
• ✅ Core Web Vitals field data trending correctly after implementation (verify in Search Console 28-day window)

Need a technical audit that identifies lazy loading issues alongside your full Core Web Vitals optimization opportunities? Contact our technical SEO team for a comprehensive performance and crawlability review.