Image Lazy Loading: When to Use It and When to Avoid It

What does image lazy loading change?

Lazy loading changes when an image is requested. It does not change the file's pixel dimensions, format or compression. Think of a long recipe page: someone opening it needs the first view promptly, but may never reach the fifteen photographs near the end. Deferring those later pictures can avoid unnecessary initial downloads.

There are three different jobs here. Resizing removes unnecessary pixels. Compression reduces the data used to store a picture. Lazy loading postpones a request. A large image can still be expensive when it eventually loads, and a small image can still appear late if its request is delayed.

Plan those jobs separately. Prepare suitable dimensions with the image resizer and compare compression where useful. Then decide which images the opening view needs. Our file-size guide covers preparation; this guide focuses on the loading decision.

How to get started without coding

You do not need to edit HTML to decide which pictures should load first. Start with one typical page, such as a product page or a long article. By the opening view, we mean the part of the page you see before scrolling.

1. Look for an existing setting. In your website administration, check the theme, image or performance settings for “lazy loading” or “defer image loading.” The name and location vary, and some services manage it automatically. If you cannot find it, ask your website maintainer before installing another plugin.
2. Keep the opening view ready. The main picture and other images visible when the page opens should load normally. If the setting offers exclusions, ask how to exclude those images. Avoid enabling a rule for every image until you know how the main picture is handled.
3. Try deferral farther down the page. Later article illustrations are a useful starting point. Use a preview or test page if available, then check the published result. Gallery images need a separate check because visitors can move through them quickly.
4. Check the reading experience. Open the page on your phone and computer. Does the main picture appear promptly? As you scroll slowly and then quickly, do later pictures appear before you need them? Does text jump when a picture arrives? Also try opening a link directly to a lower section.

If you see a problem, undo the setting you just changed and ask for help with that page. These checks can reveal obvious delays or movement, but they do not prove that the site became faster. A performance report is needed to compare loading times; the testing section below explains what to record.

You can send your maintainer this request: “Please check image lazy loading on this page. Keep the main picture and other images in the opening view loading normally, defer suitable images farther down, and reserve space so the text does not jump. Please test on mobile and desktop and compare the main image’s loading time before and after the change.” Include the page link and mention any picture that appears late.

Which images should you lazy-load?

Open a representative page without scrolling. Note which images are visible and which help a visitor understand the page. Repeat on a narrow phone and a wide desktop: a banner, heading and product gallery may occupy quite different parts of the first view.

Classify by actual placement rather than filenames or upload order. The first image in the media library is not necessarily the first image on the page. Likewise, a photograph below a long introduction on desktop might move into the opening view in a different template.

If the same image is visible initially on desktop but farther down on mobile, normal loading is the safer starting choice. The loading attribute does not offer a media query like picture does. Avoid adding screen-size scripts just to save one request; first check whether that request is a meaningful cost.

Do not treat every hidden gallery slide as a guaranteed postponed download. Gallery scripts can preload images independently of the image attributes. Test advancing the gallery quickly and returning to an earlier slide, not just scrolling down a static page.

Why the main image should not wait

Largest Contentful Paint (LCP) measures how soon the largest content element in the opening view becomes visible. This is often the main photograph, but it can also be a text block. Identify that element in your performance report before deciding which picture deserves special treatment. If it is an image, avoid lazy loading it. An early, discoverable image reference helps the browser start the work sooner; a reference inserted only after a script runs can add another delay.

Removing lazy loading does not fix every slow main image. Server response, download size and rendering can still dominate. Google's LCP optimization guide separates these stages. The Pixilo Core Web Vitals guide explains how to distinguish loading problems from layout movement.

Use the priority hint fetchpriority="high" selectively for the image you have identified as important. Giving every gallery item high priority does not establish a useful order. Adding that hint to a lazy-loaded image is also not a substitute for removing the delay from your main visible image.

Check what your CMS or gallery already does

Before installing a lazy-loading plugin, inspect the image on the published page. Your content system, theme or optimization service may already add the attribute. Look at the resulting HTML and the actual request rather than assuming a setting named “image optimization” tells you what happens.

Choose one place to manage the behavior. If an existing script replaces image URLs, wraps pictures or preloads slides, adding another mechanism can make it harder to understand why a picture appears late. Start with one page and confirm that the main image is excluded from deferral.

A CSS background is a separate case: an img loading attribute cannot be attached to a background declaration. Ask the person maintaining the template to inspect how that particular resource is discovered. Do not paste image markup into a visible editor block and assume it changes a theme's background.

Add native lazy loading to an HTML image

For an ordinary article illustration well below the opening view, keep a real image URL in src and add the loading attribute. The example paths below are placeholders: replace them with files your site actually serves, and write alt text that suits your content. Describe what an informative image shows; keep recipe instructions in the surrounding text. A purely decorative image should use alt="".

<img
  src="/images/recipe-step-04.webp"
  width="1200"
  height="800"
  loading="lazy"
  alt="Dough folded over the filling, with the edges still open"
>

A measured LCP photograph in the opening view needs a different choice:

<img
  src="/images/finished-loaf.webp"
  width="1200"
  height="800"
  loading="eager"
  fetchpriority="high"
  alt="Freshly baked loaf with a golden crust"
>

eager requests normal loading; omitting loading ordinarily has the same meaning. An explicit value can help when a template otherwise adds lazy loading automatically. It does not mean “download instantly.” The MDN image element reference explains these attributes.

The browser decides when a native lazy-loaded image is near enough to request. It can load before the picture becomes visible, so an off-screen request does not by itself mean the setting failed. Do not build your acceptance test around a fixed scrolling distance. See web.dev's native lazy-loading guide.

Reserve space and keep responsive image choices

Set width and height to the source image's pixel dimensions: the examples assume a 1200 × 800 file. These values establish its proportions; CSS can still display it at a smaller size. Copying those numbers onto a differently shaped image can reserve the wrong space. For an image that scales without cropping, responsive styling can keep those proportions:

.article-image {
  display: block;
  max-width: 100%;
  height: auto;
}

Add class="article-image" to the relevant image or adapt an existing site rule. If the design uses a fixed crop, reserve the crop's display area instead. Test the actual layout: unrelated CSS can override otherwise sensible markup.

Lazy loading does not replace srcset and sizes. Keep useful variants so the browser can choose a suitable file when it requests the image. With a picture element, the loading setting belongs on its img element. Our responsive images guide provides complete size-selection examples.

How to test the change on the published page

1. Record a baseline. Save the page URL, viewport and measured LCP element. Record the LCP time, the main image request's start time and the image data transferred before scrolling. Note whether this is a first-visit or cached test.
2. Inspect the image requests. Open the Network panel before reloading and filter for images. Record which files the opening view requests and when they start.
3. Change one loading rule. For example, remove lazy loading from the measured main image or enable it for later article illustrations.
4. Confirm the published result. Check the actual image attributes and requested URLs after any cache refresh. A local template edit alone does not change the live page.
5. Repeat and scroll. Compare equivalent test runs, then scroll both slowly and quickly, use galleries and follow a link directly to a lower section. Watch for blank areas and layout movement.

For a first-visit comparison, the browser's Disable cache option helps keep browser caching out of the test while developer tools are open. It does not clear a server or CDN cache. Chrome's Network panel documentation explains request inspection. Keep network conditions consistent and compare several runs rather than picking the best one.

Start each comparison at the top of the page, with the same viewport, network settings and observation period before scrolling. Scroll only after recording the initial results: otherwise the later image requests can distort the comparison. A saved scroll position can also make a supposedly off-screen image load immediately.

A successful change makes the important first view available promptly while later images still appear when needed. Fewer early requests are useful only if reading and navigation remain smooth. Use the PageSpeed workflow for comparing performance evidence.

Example: an article with one cover and twelve illustrations

Suppose a long article has a cover in the opening view and twelve photographs farther down. A global setting marks all thirteen images lazy. The cover appears late on a phone even though its file is already modest.

First confirm whether the cover is the reported LCP element. Remove lazy loading from it and test that change alone. Then keep selective deferral for illustrations farther down, with their display space reserved. If the first illustration is also visible on desktop, let that image load normally too.

After publishing, compare the cover's request timing and LCP across similar runs. Scroll through all twelve illustrations, jump to a section link and check that each picture appears. If results show the cover arrives early but remains hidden by an animation, investigate that display delay rather than repeatedly changing the loading attribute.

Keep lazy-loaded images discoverable

Use meaningful alt text and an actual image source. A script that leaves only a placeholder until someone clicks or scrolls needs closer inspection. Google's guidance for lazy-loaded content recommends implementations that work when content enters the viewport without depending on a user interaction event.

On a published site, use Search Console's URL Inspection to inspect the rendered page when this is a concern. Confirm that relevant image URLs appear in the rendered HTML. A performance setting is not a guarantee that every image will be indexed or that rankings will improve.

Frequently asked questions

Should every image use lazy loading?

No. Choose by placement and importance. Images needed in the opening view, especially an LCP image, should not wait for it.

Does lazy loading make an image file smaller?

No. It changes request timing. Resize or compress a separate copy when excessive dimensions or file size are the problem.

Do I need a JavaScript library?

No additional library is needed for native lazy loading of ordinary HTML images. If JavaScript is disabled, native deferral is disabled and images with real source URLs load normally. A script that stores the only source in data-src needs a separate fallback. Consider a custom mechanism only for a specific need, and test it carefully.

Why do some off-screen images still load immediately?

They may be near enough for the browser to request them, or another part of the page may preload them. Check the request initiator and the gallery or theme configuration before calling it a failure.

Does async decoding replace lazy loading?

No. The decoding hint concerns decoding and presentation, while loading concerns deferral. Do not use one as evidence that the other is configured.

Summarize withChatGPT (opens in a new tab)Grok (opens in a new tab)Google (opens in a new tab)Perplexity (opens in a new tab)Claude (opens in a new tab)