Why do scroll events break your lazy loading?

What is the technical problem with scroll events?

Scroll events only trigger when the user scrolls the page. This is where it gets tricky: if your content is already visible in the viewport on load, but you are waiting for a scroll event to load it, it will never display.

The classic case? A user opens your page on an ultra-wide screen. The lower half of the page is visible without any scrolling needed. Result: lazy-loaded images and content remain invisible because the scroll event never triggered. Googlebot faces exactly the same issue.

Scroll events also create unnecessary CPU load. Every scroll movement triggers a JavaScript check, even if nothing has changed in the visibility of the elements. This is a waste of resources that directly impacts Core Web Vitals, particularly Total Blocking Time.

How does Intersection Observer work in practice?

Intersection Observer is a native browser API that automatically monitors the visibility of an element. As soon as an element enters the viewport (or is about to enter, depending on your setup), the API triggers a callback without requiring you to manually listen for scroll events.

The beauty of the system: it works regardless of the visibility trigger. Whether the element becomes visible due to scrolling, window resizing, mobile screen rotation, or layout changes, Intersection Observer detects it. It’s code that automatically adapts to the context, not a fragile workaround.

The API also allows you to set visibility thresholds (rootMargin) to load content before it becomes actually visible. You can load your images 200px before they enter the viewport, ensuring a smooth experience without any visible whitespace for the user.

Does Googlebot really detect lazy-loaded content?

Yes, but only if your implementation is clean. Googlebot executes JavaScript and can trigger lazy loading mechanisms. The problem? It does not simulate user scroll events. If your lazy loading relies exclusively on scrolling, Googlebot sees nothing.

With Intersection Observer, Googlebot correctly detects elements that become visible. The API operates independently of scrolling: it reacts to presence in the viewport, not scrolling action. This is the fundamental difference that makes your content crawlable.

• Scroll events do not trigger if the content is already visible at load time (wide screens, high resolutions)
• Intersection Observer detects visibility regardless of the trigger (scroll, resize, rotation, layout shift)
• Googlebot does not listen to scroll events but interprets Intersection Observer correctly
• Scroll-based lazy loading breaks Core Web Vitals due to excessive CPU load
• RootMargin thresholds allow for intelligent preloading without waiting for actual visibility

Is this recommendation consistent with real-world observations?

Absolutely. Technical audits consistently show that sites using scroll listeners for lazy loading suffer from partial indexing issues. There are regular instances where Google only indexes the upper half of the content, while the lower part remains invisible in mobile rendering tests.

Search Console data often reveals a gap between the content submitted via XML sitemap and what Googlebot actually displays in the URL inspection tool. Upon closer examination, it’s almost always poorly implemented lazy loading. Intersection Observer resolves 90% of these cases.

The window resizing aspect mentioned by Martin Splitt is not anecdotal. Tests show that 12 to 18% of desktop sessions on certain e-commerce sites involve window resizing (users switching from one screen to another, adjusting their browser). If your content disappears during these moments, you lose conversions.

What limitations should you know about Intersection Observer?

Browser support is no longer an issue: all modern browsers (including Safari since iOS 12.2) support the API. The real pitfall is the order of JavaScript execution. If you initialize your observer after the elements are already visible, they will not load.

Some lazy loading libraries (particularly older versions of jQuery plugins) still use scroll events under the hood, even if their documentation claims to be "modern". [To be verified] systematically in the source code of the library you are using. Check the event listeners in DevTools to be sure.

Also, be cautious with dynamic content loaded afterward (AJAX, infinite scroll). If you add elements to the DOM after initializing the Observer, you must explicitly observe them using the .observe() method. This is a common mistake that leaves content unloaded.

When does lazy loading still cause problems?

Critical content above the fold should never be lazy loaded. It’s obvious, but there are still sites that lazy-load their hero image or H1. Intersection Observer or not, it delays the First Contentful Paint and damages Core Web Vitals.

CSS background images are a borderline case. Intersection Observer works on DOM elements, but if you load your backgrounds via JavaScript based on visibility, ensure that Googlebot can see the final images. The URL inspection tool is your best friend here.

How to migrate from scroll-based lazy loading to Intersection Observer?

Start by auditing your current implementation. Open DevTools, Performance tab, and record a page scroll. If you see dozens of scroll event listeners firing continuously, you have a problem. Also, check the Event Listeners tab to identify which scripts are listening for scroll.

The migration itself is straightforward. Replace your addEventListener('scroll') with an IntersectionObserver targeting the same elements. Most modern frameworks (React, Vue, Angular) have dedicated hooks or directives. For WordPress, plugins like WP Rocket or Autoptimize already use Intersection Observer in their recent versions.

Always test with the URL inspection tool in Search Console after migration. Compare the raw HTML rendering with the JavaScript rendering. If elements are missing, your observer is not triggering correctly. Also, check on various simulated screen sizes (mobile, tablet, large desktop).

What technical errors should be absolutely avoided?

Do not set a negative rootMargin without a valid reason. A rootMargin of -50px means the element must be 50px inside the viewport before loading. This creates visible whitespaces and degrades the user experience. A positive rootMargin (200px for instance) is preferred for preloading content.

Avoid lazy loading elements with critical text (paragraphs, headings). Googlebot extracts text from the DOM, but if your paragraphs are hidden behind a poorly configured observer, you lose indexable content. Lazy loading should target media (images, iframes, videos), not HTML text.

Don’t forget the alt attributes of lazy-loaded images. They must be present in the initial HTML, even if the src is empty or points to a placeholder. Googlebot reads the alt before the actual image loading. A missing alt equals a lost SEO opportunity.

How to verify that the implementation is SEO-friendly?

Use a JavaScript rendering test with tools like Puppeteer or Playwright. Simulate different viewport sizes and check that all lazy-loaded elements appear correctly in the final DOM. Compare with a test where JavaScript is disabled to identify what depends on JS.

Check your server logs for Googlebot requests. If you see that certain images are never crawled even though they are present on your pages, that’s a warning signal. Cross-reference with Search Console coverage reports to identify affected URLs.

Measure the impact on Core Web Vitals before and after migration. Proper lazy loading enhances LCP (Largest Contentful Paint) by prioritizing visible resources. If your scores stagnate or degrade, there’s a problem with your configuration. PageSpeed Insights will tell you exactly which resources delay rendering.

• Replace all addEventListener('scroll') with IntersectionObserver instances
• Set a positive rootMargin (100-200px) to preload content before visibility
• Exclude any content above the fold (hero, H1, navigation) from lazy loading
• Test JavaScript rendering in Search Console with the URL inspection tool
• Ensure alt attributes are present in the initial HTML, not loaded dynamically
• Measure Core Web Vitals before/after to confirm improvements (especially LCP and TBT)