Lazy Loading Images Without Hurting LCP or SEO

Lazy loading postpones work that a visitor may never need. It is most useful for media well below the initial viewport, not as a blanket attribute added to every image. A safe implementation preserves discoverable URLs, predictable layout, and a fast first screen while reducing unnecessary early requests.

Classify media by when it is needed

Inventory images, embedded videos, maps, and other frames by template. Mark which are visible immediately, which become visible after a small scroll, and which are deeply optional. Visibility priority should drive the policy, not whether a file happens to be large.

Use the image resizer calculator to determine dimensions and aspect ratios for reserved image areas. Lazy loading does not remove the need for correctly sized files or stable layout. A deferred oversized image can still be expensive when it eventually loads.

Consult web.dev's browser image lazy-loading guide for native behavior and caveats. Browsers may request an image before it enters the viewport, using their own distance thresholds and heuristics. Do not depend on an exact pixel boundary or a fixed number of saved requests.

Identify the likely Largest Contentful Paint candidate separately for each major viewport. A media block below the fold on a tall monitor may be visible on a shorter layout or move upward when a promotion disappears. Template-level assumptions need representative device checks.

Prefer native loading for ordinary images

Use a real src or srcset so the browser can discover the resource. Native lazy loading generally avoids the complexity of replacing placeholder attributes with JavaScript. A simple below-the-fold example is:

<img
src="/media/workflow-example.webp"
width="1200"
height="800"
loading="lazy"
decoding="async"
alt="A workflow with review and publication stages"
>

The width and height establish an intrinsic aspect ratio, while responsive CSS can still scale the image. The decoding hint is independent of loading and does not guarantee that decoding happens at a particular time. Keep the alternative text appropriate to the image's actual purpose.

Do not place loading="lazy" on the likely LCP image. Leave it eager, and consider a high fetch-priority hint only when justified by measurement. Deferred discovery of the primary visual can erase the benefit of every image optimization that follows.

The MDN image reference documents how loading, dimensions, decoding, and source selection interact. Keep those responsibilities separate: source selection chooses the appropriate file, loading controls timing, and dimensions help layout before the file arrives.

Avoid adding a custom observer merely because it offers more configuration. Every custom system introduces lifecycle concerns, fallback behavior, and potential differences between rendered content and the initial document. Use it only when the product requirement exceeds what native behavior provides.

Treat iframes as larger dependencies

An embedded frame may load scripts, fonts, images, and its own network connections. Deferring it can save more than the size of its initial document. Use loading="lazy" on suitable below-the-fold frames and reserve a stable display area.

<iframe
src="https://www.youtube-nocookie.com/embed/VIDEO_ID"
title="Product setup walkthrough"
width="560"
height="315"
loading="lazy"
allowfullscreen
></iframe>

Replace the placeholder video identifier with a real authorized embed. Review the provider's current privacy and consent requirements; a privacy-oriented hostname is not a universal substitute for a consent policy. The frame's title should identify its purpose for assistive technology users.

For especially expensive optional embeds, consider a click-to-load facade: show a lightweight preview and a real button that creates the frame after a deliberate action. Account for keyboard focus, accessible naming, and a fallback link to the original resource. Do not make essential instructions available only inside an unloaded player.

A facade is different from passive lazy loading. It can reduce third-party work until the visitor requests it, but introduces an interaction step. Explain that tradeoff to the design team and measure whether it suits the task. A tutorial page may require different behavior from a decorative marketing video.

Preserve search discovery and essential content

Search crawlers do not necessarily scroll or interact like users. Keep important text and links available without requiring a manual action. For media, preserve standard resource attributes where possible and verify how the rendered page exposes the content.

Google's lazy-loading guidance recommends implementations that do not depend on unsupported user interactions for discovery. Test the rendered output with URL inspection tools rather than assuming a local scroll test proves crawler visibility.

Do not confuse lazy loading media with hiding entire content sections until clicked. A full article body or product specification may have different rendering and indexing requirements than an image far below it. Essential content availability should remain a separate architectural decision.

If a custom implementation is necessary, make failure behavior explicit. What happens when JavaScript fails, an observer is unavailable, or a component unmounts during navigation? Avoid placeholders that remain blank forever. Where appropriate, preserve meaningful links or server-rendered alternatives instead of relying on one successful script path.

Coordinate this work with the existing responsive image pipeline. Deferring requests and selecting efficient resources complement each other, but they solve different problems. Do not rebuild sizing logic simply to add a loading policy.

Test scrolling, navigation, and constrained devices

Record a cold navigation and inspect which media requests begin before any scroll. Confirm that the hero is not delayed and that optional content is deferred as intended. Then scroll rapidly to reveal whether users encounter long blank gaps on slower connections.

Test anchor links that jump directly to deep sections, browser history restoration, and client-side route changes. These paths can reveal lifecycle bugs that never appear during a slow top-to-bottom scroll. A page should load media near the restored position, not wait for an event that already occurred.

Check layout during loading and failure. The existing CLS debugging guide can help diagnose shifts without conflating them with request timing. Inspect both loaded dimensions and placeholders, particularly when captions or error messages change the reserved area.

Compare transferred bytes, initial requests, LCP, and the time media becomes usable after scrolling. A smaller initial payload is not automatically a better experience if every lower section appears late. Document which templates use each policy and retest when layout changes move media into the initial viewport.

Key takeaways

• Lazy-load optional offscreen media, not the likely LCP image.
• Keep standard source attributes and reserve image dimensions.
• Consider facades for expensive, nonessential third-party embeds.
• Verify crawler discovery independently from manual scrolling.
• Test deep links, restored positions, and slow connections.