Google cautions: default lazy loading can delay LCP and hinder indexing

On Google’s Search Off the Record podcast, Martin Splitt—speaking with John Mueller—warned that lazy-loading above-the-fold images can push back Largest Contentful Paint (LCP) and sometimes create jarring layout shifts. He also noted that some JavaScript lazy-loading libraries can keep Google from seeing image URLs if they never appear in standard src/srcset attributes in the rendered HTML.

Lead & why it matters

Google says making every image lazy by default can slow down your page’s perceived load—especially when it includes hero images. Because LCP is one of the Core Web Vitals, letting the browser delay that primary visual almost guarantees a worse score and a poorer user experience. Splitt put it plainly: using lazy loading on an image that’s immediately visible is “most likely going to have an impact on your Largest Contentful Paint… almost guaranteed.”

Background: what LCP measures

LCP tracks when the largest text block or image in the initial viewport finishes rendering. Modern browsers normally detect a hero image early and fetch it with high priority. When you add loading=”lazy” to that same image, you’re telling the browser to de-prioritize it—so scripts, CSS, and other assets get bandwidth first, and the hero waits in line. On slow networks or low-end devices, the delay is amplified. If you also omit explicit width and height, the late-arriving image can shift the layout and feel “jarring.”

What Google said (and showed)

• Don’t lazy-load above-the-fold images. Splitt cited a real example on developers.google.com where the CMS defaulted all images to lazy loading—“not great,” he said—because it pushes back the hero image and LCP.

• Prefer native lazy loading for noncritical media. Browsers support a built-in loading attribute for images and iframes. Use that for below-the-fold content; let the browser handle it without heavy JavaScript.

• Beware custom attributes. Some older/custom libraries stash URLs in nonstandard attributes like data-src. If those URLs never move into src/srcset in the rendered DOM, Google may not index the images at all.

How lazy loading delays LCP (in practice)

1. Without lazy loading, the preload scanner discovers the hero image in HTML and starts the request immediately, at high priority.

2. With loading=”lazy” on that hero:
   • The browser lowers the priority of the fetch.

   • It waits for layout and other work before requesting the image.

   • By the time the hero downloads, bandwidth is busy with scripts, styles, and other assets.
     Result: the largest element paints later → higher (worse) LCP.

Indexing risks with some libraries

• If your lazy-loader never swaps data-src → src (or data-srcset → srcset) in the rendered HTML, Google may not “see” the image during indexing.

• Native loading=”lazy” avoids this pitfall entirely for standard cases and is now widely supported (WordPress enables native lazy loading by default).

How to verify your pages

Use Search Console → URL Inspection and review the rendered HTML (not just the screenshot). Confirm that:

• Above-the-fold images (especially the hero) do not have loading=”lazy”.

• Final markup exposes real URLs in src/srcset for images you want indexed.

• Critical images include explicit width and height to prevent layout shifts.

Splitt’s guidance: if the rendered HTML shows your image URLs in the src attribute of <img>, “then you will be fine.”

Ranking impact

Core Web Vitals influence ranking, but Splitt characterized it as “a tiny, minute factor in most cases.” Translation: UX comes first. Don’t chase the metric at the expense of users, but don’t sabotage LCP by lazy-loading your hero.

What to do now (practical playbook)

Do

• Eager-load the hero and other above-the-fold images (omit loading=”lazy”; consider <link rel=”preload” as=”image” imagesrcset=”…” imagesizes=”…”> for complex heroes).

• Set width and height (or aspect-ratio) on critical images to stabilize layout.

• Use native loading=”lazy” for images/iframes below the fold.

• If you must use a library (e.g., for placeholders or transitions), ensure it swaps to src/srcset in rendered HTML.

• Monitor LCP trends in Search Console and lab tools (Lighthouse, Chrome DevTools Performance panel) and validate in field data (CrUX if available).

Avoid

• Site-wide defaults that make all images lazy.

• Leaving hero images without dimensions.

• Libraries that keep URLs only in data-* attributes at render time.

Reader-intent quick answers

Q: Should I turn off lazy loading everywhere?
No. Keep lazy loading for noncritical, below-the-fold media. Just don’t lazy-load images that are visible on initial load (e.g., the hero).

Q: How can I tell which image is my LCP?
Run Lighthouse or Chrome DevTools; they’ll identify the LCP element. In field data, check Search Console’s Core Web Vitals report.

Q: Do I need a JS library if browsers support loading=”lazy”?
Usually not for static images/iframes. Use a library only if you need advanced behaviors (progressive placeholders, animations), and make sure the final HTML exposes src/srcset.

Q: Can this affect rankings?
Yes, but modestly. Still worth fixing because it meaningfully improves real user experience and can help meet CWV thresholds.

Q: What’s the fastest fix if my LCP is poor due to lazy loading?
Remove loading=”lazy” from the hero, add width/height, consider preloading the hero image, and re-test.

Bottom line

Lazy loading is an opt-in for noncritical content—not a site-wide default. Keep above-the-fold images eager, ensure URLs appear in standard attributes in the rendered HTML, and verify changes with Search Console and lab/field measurements. This avoids self-inflicted LCP delays and indexing blind spots while keeping the UX snappy.