Native loading=”lazy” can defer off-screen images, but applying it to every image can delay a hero or other likely LCP resource. The decision depends on initial viewport position, page templates, image size, and how content shifts across devices.

The decision this guide supports

Defer images that are truly outside the initial viewport without delaying the image most important to perceived loading.

Repeatable method

1. Map images by template

For mobile and desktop, label each image as initial viewport, near viewport, or far below the fold. Templates can place the same component differently.

2. Keep likely LCP images eager

Do not add loading=”lazy” to the primary hero or other image consistently selected as LCP. Keep its source discoverable in HTML.

3. Add native lazy loading selectively

Use loading=”lazy” on appropriate img elements and retain width and height. Avoid a JavaScript library unless native behavior cannot meet a documented requirement.

<img src="step-04.webp" loading="lazy" decoding="async" width="960" height="640" alt="Network request after scroll">

4. Observe request boundaries

Reload with cache disabled and a slow network. Record which images request before scrolling and when a deferred image starts as it approaches the viewport.

Viewport-boundary request fixture

Build an illustrative article containing four 960 × 640 images at fixed document positions: hero at 0 px, diagram A at 900 px, diagram B at 1800 px, and diagram C at 3000 px. Keep the viewport at 390 × 844 CSS pixels. The positions are controlled inputs, not a claim about when any browser will request them.

Request-boundary check

  • List each image role, its loading value, and its initial distance from the viewport.
  • Before scrolling, note which image requests begin and which currentSrc each one selects.
  • Scroll in repeatable checkpoints and record when each lazy request starts relative to the viewport.
  • Confirm that the likely LCP image is requested without waiting for interaction.
  • Decision rule: use lazy loading only where it avoids an early transfer without creating a blank state or delaying visible content.

Disable cache, use one documented network profile, reload without scrolling, and preserve the Network log. Then scroll in 400-pixel steps, pausing after each step, and note the scroll position at which every deferred request begins. Repeat with a desktop viewport and with Diagram A set to eager. Record the LCP element in each run. The purpose is to locate the browser’s effective lazy-loading boundary for this template, not to establish a universal pixel threshold.

What to record

Record template, viewport height, image position, loading attribute, request start relative to navigation, LCP element, transferred bytes before interaction, browser version, and date.

Do not turn a lab result into a universal rule

A result belongs to the source file, encoder, settings, browser, viewport, cache state, and date that produced it. Repeat the test on representative files before changing a production workflow.

Common mistakes

  • Adding lazy loading through a blanket filter
  • Lazy-loading the likely LCP image
  • Omitting dimensions from deferred images
  • Assuming deferred means the file will never load

Verification checklist

Run repeated mobile and desktop traces, inspect the LCP resource, scroll at realistic speed, use keyboard navigation, and verify images still appear with JavaScript disabled when relying on native loading.

Primary references

Related lab notes

About this guide

We distinguish documented platform behavior from our workflow recommendations. See the testing methodology, editorial policy, and corrections log.