Google clarifies lazy-loading: the LCP penalty hiding in your hero images

Lazy loading and LCP: how default lazy images can slow real pages

This analysis covers the trade-offs of lazy loading in the viewport, the mechanisms that delay LCP, and the fixes that protect both organic visibility and paid landing-page performance. The focus is on above-the-fold assets, browser priority behaviors, and indexing pitfalls from nonstandard lazy-loading libraries, as highlighted by Google’s developer advocates.

Key Takeaways

Marketers working toward Core Web Vitals and landing-page performance goals should treat lazy loading as opt-in for noncritical content, not a blanket setting.

• Do not lazy-load hero or any above-the-fold image: it shifts the request to a lower-priority queue, commonly adding 200-800 ms to LCP on mid-tier mobile networks (assumption based on Chrome priority rules and typical hero sizes) - reducing conversion headroom while offering negligible ranking gain [S1][S2][S3]. So what: expect a measurable conversion lift and improved PageSpeed Insights scores by exempting the LCP image.
• Use native lazy-loading and standard attributes: use loading="lazy" for below-the-fold images and iframes, and ensure final HTML uses src/srcset (not data-src) to avoid missed indexing [S1][S2][S5]. So what: reduces crawl and index risk and simplifies debugging in Search Console.
• Promote the hero image: set width and height, and consider fetchpriority="high" and/or rel=preload for the LCP asset per web.dev guidance [S3][S4]. So what: earlier fetch = lower LCP at the 75th percentile, which is what CrUX reports.
• Expect low ranking impact but real UX impact: Google reiterates CWV is a tiny factor for rankings; field data still correlates speed with engagement and conversion [S1][S6]. So what: prioritize UX and conversion over chasing small ranking deltas.
• Framework defaults matter: many CMS and framework components default to lazy. Audit and set priority or eager equivalents for above-the-fold images. So what: prevents regressions during redesigns or library upgrades.

Situation Snapshot

Google’s Search Off the Record podcast discussed how lazy loading above-the-fold images delays LCP and how some lazy-loading libraries can hide URLs from Google if they never resolve into src or srcset in rendered HTML. See the recent episode [S2]. Google also advised verifying rendered HTML in Search Console rather than relying on screenshots [S1][S2]. The LCP good threshold remains under 2.5 s at the 75th percentile of page loads (field data) [S3]. Native lazy loading via the loading attribute on images and iframes is broadly supported and preferred over custom JS solutions [S5]. Google reiterated that CWV signals contribute modestly to ranking, so the business case is mostly UX and conversion, not SEO alone [S6].

Breakdown & Mechanics

The browser’s preload scanner and priority system fetch in-viewport, large images early. When developers add loading="lazy" to a hero image, they instruct the browser to defer its request until after layout progress or viewport heuristics trigger. That changes scheduling: hero marked lazy - deprioritized request - scripts, styles, and other assets take bandwidth - hero arrives later - LCP increases. On constrained CPU or bandwidth, the delay compounds. If width and height are missing, the late image can also move layout, inflating CLS and making the experience feel jarring [S1][S3].

For indexing, older or custom lazy-loading libraries often stash URLs in data-src or custom attributes until JS runs. If the renderer does not surface the real URL in src or srcset in the final DOM, Google may not see it, so images can be missed for indexing. Native lazy loading reduces this risk because the browser handles deferment while keeping URLs in standard attributes [S1][S2][S5].

Operationally, think in terms of an LCP budget. Example model (assumption for illustration): on a 4G connection (~1.5-3 Mbps effective), a 200-300 KB hero JPEG or WebP fetch might take ~150-300 ms of download time plus ~100-200 ms of overhead. If lazy scheduling defers the request by a main-thread or layout phase and a lower network priority, 200-800 ms of extra delay is plausible. That alone can push a 2.3 s LCP into the needs-improvement band, especially at the 75th percentile that Chrome User Experience Report (CrUX) data reflects [S3].

Impact Assessment

Paid Search and landing pages

• Direction: Negative if heroes are lazy-loaded; positive if corrected.
• Magnitude: Expect modest CPC or Quality Score effects at most; the bigger lever is conversion rate via faster perceived load. A 200-800 ms LCP gain can reduce abandonment on mobile. Evidence-based expectation: better LCP typically correlates with improved engagement; formal QS linkage to LCP is not documented by Google Ads (speculation).
• Actions: Audit top ad URLs for hero lazy loading; A/B test eager hero plus fetchpriority vs default lazy; monitor GA4 engagement rate and conversion per session alongside PageSpeed Insights field LCP.

Organic and SEO

• Direction: Slight ranking benefit if LCP improves from poor or needs improvement to good, but weight is limited [S6].
• Magnitude: Small direct SEO effect; larger indirect gains from reduced pogo-sticking and better user signals (speculation).
• Actions: Exempt the LCP element from lazy loading; add width and height; consider rel=preload or fetchpriority="high"; validate in Search Console rendered HTML; confirm images resolve to src or srcset (not data-src).

Content and Creative

• Direction: Positive when hero asset size and format are reconsidered.
• Magnitude: Medium; encoding and dimensions often save more than 100 KB without visible quality loss (WebP or AVIF, responsive sizes) [S3].
• Actions: Provide responsive image sets with srcset and sizes, compress assets, avoid CSS-only heroes if they complicate preloading.

Engineering and Operations

• Direction: Favor standard browser features over custom JS; align framework defaults.
• Magnitude: High risk reduction by removing nonstandard lazy libraries that hide URLs.
• Actions: Inventory templates and components that set loading="lazy" by default; add exceptions or priority flags for heroes; remove or refactor libraries using data-src; add automated checks in CI to flag above-the-fold lazy images and missing width or height.

Monitoring points

• Field LCP at p75 via the CrUX report in Search Console.
• CLS for the hero area after width and height changes (target under 0.1) [S3].
• Rendered HTML in URL Inspection to verify src or srcset exposure.
• Regression guardrails in Lighthouse CI for an LCP budget (for example, under 2.5 s lab target on representative mobile).

Scenarios & Probabilities

• Base (Likely): Teams exempt above-the-fold images from lazy loading and apply fetchpriority or preload for the LCP asset. LCP improves by ~200-500 ms on key pages (assumption), moving many URLs into the good band, with small SEO lift and modest conversion gains.
• Upside (Possible): Combined fixes - eager hero, responsive images, compression, critical CSS - yield 500-1000 ms LCP improvement at p75, driving noticeable organic stability and a 2-5% conversion rate lift on mobile landing pages (assumption; lift varies by funnel).
• Downside (Edge): Sites keep blanket lazy loading and rely on custom libraries with data-src. Google misses some images for indexing on JS-challenged renders; LCP remains over 4 s on mobile, hurting conversion and limiting visibility on competitive SERPs.

Risks, Unknowns, Limitations

• No direct Ads documentation ties LCP to Quality Score; conversion impact estimates are inferred from performance literature (speculation).
• Framework behavior varies (for example, Next.js, Nuxt, Shopify themes); defaults and priority flags must be verified per stack.
• LCP drivers are multifactor: render-blocking scripts, critical CSS, server TTFB. Fixing lazy heroes alone may not reach under 2.5 s without broader work [S3].
• Device and network variability: p75 improvements depend on audience mix in CrUX; lab gains may not match field results.
• Potential falsifier: if field data shows no LCP change after removing lazy from heroes, then bottlenecks lie elsewhere (for example, TTFB or client JS), contradicting lazy loading as the primary cause.

Sources

• [S1]: Search Engine Journal, Aug 2025, coverage - "Google: Why Lazy Loading Can Delay Largest Contentful Paint (LCP)".
• [S2]: Google Search Central, Aug 2025, podcast or video - "Search Off the Record" episode discussing lazy loading, LCP, and indexing of images (recent episode).
• [S3]: web.dev, ongoing documentation - "Optimize LCP" and Core Web Vitals thresholds (under 2.5 s good, 2.5-4 s needs improvement, over 4 s poor).
• [S4]: web.dev, guide - "Preload critical assets" and using fetchpriority="high" for hero images.
• [S5]: web.dev, guide - "Native lazy-loading for images and iframes".
• [S6]: Search Engine Journal, prior coverage - "Google’s Mueller on Core Web Vitals as a minor ranking factor".