Guide · Networking

How Lazy Loading Images Affects Page Speed

Updated 2026-08-09 · 4 min read

Lazy loading means the browser does not fetch an image until it is close to the viewport. That cuts work on the first paint: fewer requests, less contention with CSS and the hero asset. It also has a well-known footgun - if you lazy-load the image that is the Largest Contentful Paint, you have delayed the metric you were trying to improve.

This is a markup and bytes problem, not a DNS problem. Lazy Load Tester is there to watch Intersection Observer behavior and timing in the tab. Lighthouse Simulator is for talking through device and throttle presets. Neither is an excuse to fetch origins you do not control.

What loading="lazy" actually delays

On a supporting browser, loading="lazy" on <img> (and iframe) tells the engine to postpone the network request until the element is near the viewport. Images already on screen, or about to be, should still load promptly. Images in a long article below the fold wait.

That helps:

  • list pages with 40 product thumbnails,
  • article bodies with a dozen figures,
  • infinite-scroll feeds.

It does not help if the first screen is a single uncompressed photograph. The attribute never ran.

loading="eager" (or omitting lazy) is the correct default for the logo-sized LCP image, a full-bleed hero, and anything in the first viewport on mobile. Pair that with fetchpriority="high" when the hero is clearly the LCP candidate.

Background images in CSS cannot use loading. They need other tactics (smaller files, media on source, or not putting a 2000px JPEG in background-image on every page).

LCP: the hero you should not defer

Largest Contentful Paint is usually a big image, a heading, or a video poster. If your design uses a photograph in the first screen, that file is on the critical path.

A typical bad pattern:

<img src="/hero.jpg" loading="lazy" alt="" />

The browser may wait to start hero.jpg until layout and proximity checks finish. Your LCP time moves right. The rest of the page’s lazy thumbnails were never the issue.

A better pattern:

<img
  src="/hero.jpg"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="Product on a bench"
/>

Then loading="lazy" on the gallery below.

Lazy Load Tester is useful for seeing when a deferred image starts relative to scroll. It will not magically pick your LCP element - you do that by looking at the first screen.

Placeholders, dimensions, and layout shift

Lazy images that pop in without reserved space cause Cumulative Layout Shift. Set width and height (or an aspect-ratio box) so the layout hole exists before the bytes arrive. A solid or blurred placeholder is optional polish; the reserved box is not optional if you care about CLS.

srcset and sizes still matter. Lazy-loading a 2400px image into a 360px column wastes the delay you just bought. Serve a width the layout will actually use.

Compression is still the larger lever. A lazy 2 MB image is a slow image that starts later. Convert and compress the files you ship - DevOkk’s image tools handle that locally - then decide which of those files are allowed to be lazy.

How to inspect behavior in the tester

  1. Open Lazy Load Tester without an account.
  2. Use it to exercise lazy versus eager images, observer thresholds, and what happens when you simulate a slower network in the page’s own controls.
  3. Watch request timing as you scroll: deferred images should stay quiet until they approach the viewport; the first-screen image should not wait on that scroll.
  4. If you are deciding whether a page shape can survive a mid-range phone, use Lighthouse Simulator for presets, then run real Lighthouse on a URL you host.

Do not treat the tester as a license to pull arbitrary third-party pages. Work with markup and assets you are allowed to test.

When lazy loading is the wrong default

  • One hero, no below-the-fold images - there is nothing to defer.
  • Printable or offline-first documents - you may want everything fetched up front.
  • Above-the-fold carousels - the first slide is LCP; later slides can be lazy.
  • CSS background heroes - fix the file weight; loading will not apply.

Also wrong: lazy-loading as a substitute for pagination. If you dump 500 images into the DOM with loading="lazy", you still pay for DOM, decode, and memory as they come in. Smaller pages win.

Ping and DNS will not catch this class of slowness. A 15 ms Ping Test to the origin and a 3-second LCP from a lazy hero are compatible facts.

Eager the hero, lazy the rest

Mark the first-viewport image eager and sized. Mark the rest lazy. Confirm the timing in Lazy Load Tester. If you need a score conversation before you write CSS, use Lighthouse Simulator. For the files themselves, compress them before you argue about the attribute - How to Compress Images for the Web.

Frequently asked questions

Should the LCP image be lazy-loaded?

No. The largest above-the-fold image should load eagerly (loading="eager" or omit lazy) and often deserves fetchpriority="high". Lazy-loading it delays Largest Contentful Paint.

Is `loading="lazy"` enough by itself?

It defers offscreen images. You still need width/height (or aspect-ratio) to avoid layout shift, and compressed files so the bytes that do load are small.

Does the lazy-load tester send my production URL?

The tester is for exercising lazy-load behavior and Intersection Observer in the browser. It is not a substitute for Lighthouse against a URL you host. Use it to understand markup and timing, not to probe someone else’s origin.

Native lazy load vs a JavaScript library?

Native loading="lazy" is enough for most content images. A library is justified when you need older-browser behavior, custom placeholders, or non-image lazy loading. Libraries add their own bytes.

Does lazy loading help SEO?

It can help Core Web Vitals if you do not lazy-load the LCP image and you reserve space. It will not rescue a 3 MB PNG in the hero. Google’s crawler can still discover img src URLs.

Where do I preview a Lighthouse-like score without a full audit?

Lighthouse Simulator uses device and throttle presets. For a real trace, run Chrome Lighthouse on a page you control.

More reading that links back to the same tools and workflows.