When Lazy Loading May Not Be the Best Choice

What lazy loading changes

Lazy loading postpones the retrieval or initialization of a resource until the browser determines that it is likely to be needed. For images and iframes, this can often be implemented with the native HTML loading="lazy" attribute.

<img
  src="/images/project-detail.jpg"
  alt="Finished woodwork in a remodeled kitchen"
  width="1200"
  height="800"
  loading="lazy"
>

This approach can reduce initial network activity, save bandwidth, and prevent off-screen content from competing with more important resources. It is a practical part of website performance, particularly on pages containing long image galleries, embedded maps, videos, or other resource-heavy sections.

The tradeoff is that a lazy-loaded resource is intentionally given a later start. That is beneficial when the resource is not yet relevant. It becomes counterproductive when the user is already waiting to see it.

When lazy loading may be the wrong choice

A resource generally should not be deferred when it is important to the first meaningful view of the page. Common examples include:

• a prominent hero image visible as soon as the page opens;
• an image likely to become the page’s Largest Contentful Paint element;
• a product image that is central to the page’s purpose;
• a chart, diagram, or screenshot needed to understand the opening explanation;
• the first visible image in a gallery or carousel;
• an embedded interface that the user is expected to use immediately; and
• content close enough to the viewport that a user is likely to reach it before delayed loading completes.

In these situations, lazy loading can introduce a blank area, placeholder, or visible loading transition precisely where the page is trying to establish meaning. The page may transfer fewer bytes during its earliest moments while still feeling slower to the person using it.

This distinction matters because technical efficiency and user-perceived responsiveness are related, but they are not identical. A page should not improve one measurement by withholding the content that makes the page useful.

Hero images and Largest Contentful Paint

Large hero images frequently become candidates for LCP, a performance metric that observes when the largest visible content element finishes rendering. If the browser is instructed to lazy load that image, its request may begin later than it otherwise would.

For an important first-view image, the markup will often be more appropriate without loading="lazy":

<img
  src="/images/homepage-hero.jpg"
  srcset="/images/homepage-hero-800.jpg 800w,
          /images/homepage-hero-1600.jpg 1600w"
  sizes="100vw"
  width="1600"
  height="900"
  alt="A bright living room with restored wood flooring"
>

The absence of a lazy-loading instruction allows the browser to handle the image through its normal loading behavior. When testing identifies the image as especially important, fetchpriority="high" may provide an additional browser hint:

<img
  src="/images/homepage-hero.jpg"
  width="1600"
  height="900"
  alt="A bright living room with restored wood flooring"
  fetchpriority="high"
>

fetchpriority="high" should be used selectively. If many resources are labeled as high priority, the signal becomes less useful and those resources may compete with one another. Priority hints support browser scheduling; they do not replace good document structure, image sizing, compression, or testing.

When lazy loading usually helps

Lazy loading is most valuable when the browser would otherwise retrieve substantial resources that the user cannot yet see and may never reach.

Good candidates commonly include:

• images far below the initial viewport;
• later images in a long gallery or project archive;
• video players located deeper in an article;
• maps that appear after the primary page content;
• social media embeds;
• third-party widgets that are not needed immediately; and
• secondary slides in a carousel when only the first slide is initially visible.

Embedded media can be particularly expensive because an iframe may initiate scripts, stylesheets, tracking requests, and additional connections. Deferring an off-screen iframe can therefore avoid more work than deferring a single image.

<iframe
  src="https://example.com/embedded-map"
  title="Map showing the project location"
  width="800"
  height="450"
  loading="lazy"
></iframe>

In some cases, a lightweight preview image with an intentional “Load video” or “Open map” control is more appropriate than automatically initializing the full embed. That decision should remain clear to the user and preserve keyboard access, meaningful labels, and expected functionality.

The first viewport requires judgment

“Above the fold” is often used as shorthand for content visible without scrolling, but modern pages do not have one fixed fold. The initial viewport changes with screen size, orientation, browser controls, text scaling, responsive layout, and user preferences.

An image that begins below the viewport on a laptop may appear immediately on a tall mobile screen. A two-column layout may become a single column, moving an image much closer to the beginning of the page. Larger text settings may move the same image farther down.

This is one reason blanket rules are unreliable. A useful decision considers:

• where the resource appears across common viewport sizes;
• whether the opening content depends on it;
• how quickly a user is likely to encounter it;
• the size and cost of the resource;
• whether an appropriate placeholder preserves layout stability; and
• whether delayed loading remains smooth on slower devices and connections.

Responsive layout changes more than visual arrangement. It also changes when content becomes relevant. Loading decisions should be evaluated within the layouts people actually receive.

A practical resource-prioritization process

Rather than starting with “lazy load every image,” begin by identifying the role each resource plays during the page visit.

1. Identify the page’s essential opening content

Determine what a visitor needs in order to understand the page and begin using it. This may include a heading, introductory text, navigation, a primary product image, or a visual that explains the subject.

These resources deserve early consideration because they establish the page’s purpose. Not every visible decorative element needs elevated priority, but essential content should not be delayed without a clear benefit.

2. Find resources that are genuinely off-screen

Review long galleries, related-content sections, maps, video embeds, and lower-page illustrations. These are often strong lazy-loading candidates because they can be requested closer to the moment they are needed.

3. Consider the cost of each resource

A small image and a third-party video player do not create the same load. Look beyond the number of elements and consider file size, script execution, external connections, rendering work, and the possibility that a resource will trigger additional downloads.

4. Preserve space before the resource arrives

Lazy loading should not cause the surrounding page to jump when an image appears. Include image dimensions or use a stable CSS aspect ratio so the browser can reserve the required space.

Width and height attributes are especially useful:

<img
  src="/images/case-study-03.jpg"
  alt="Built-in shelving along a finished interior wall"
  width="1200"
  height="800"
  loading="lazy"
>

The browser can use these dimensions to calculate the image’s aspect ratio while still allowing responsive CSS to scale it appropriately.

5. Test the page as a sequence, not only as a score

Observe what appears first, what remains blank, and what happens when someone begins scrolling quickly. A performance report can reveal request timing and rendering delays, but direct observation reveals whether the page feels coherent.

The goal is not to maximize the number of deferred requests. It is to create an orderly arrival of information.

Implementation guidance for modern websites

Prefer native lazy loading when it meets the need

Modern browsers support native lazy loading for images and iframes through the loading attribute. Native behavior is generally simpler and more resilient than a JavaScript-only implementation.

The browser determines the exact distance at which a lazy-loaded resource begins loading. That threshold can vary based on browser behavior and connection conditions. Native lazy loading should therefore be treated as a browser-managed scheduling tool, not as a promise that loading will begin at one fixed scroll position.

Do not hide meaningful content behind JavaScript unnecessarily

The image should normally remain present in the HTML with a usable src, descriptive alternative text where needed, and intrinsic dimensions. Replacing meaningful markup with script-dependent placeholders can make the page more fragile and may weaken accessibility or fallback behavior.

This is consistent with progressive enhancement: begin with a functional document, then add behavior where it improves the experience.

Distinguish lazy loading from other forms of deferral

Images and iframes use the native loading attribute, but other resources follow different loading models. Scripts may use defer or async; fonts have their own discovery and display behavior; stylesheets affect rendering; and interactive components may delay initialization through JavaScript.

These techniques share a concern with timing, but they are not interchangeable. Each resource should be evaluated according to how the browser discovers it, what it blocks, and what the user needs from it.

Be cautious with CSS background images

A prominent visual implemented as a CSS background image may be discovered later than an image placed directly in the HTML. If the visual is meaningful content or a likely LCP element, an HTML <img> or <picture> element often provides clearer semantics and more direct loading behavior.

CSS backgrounds remain appropriate for genuinely decorative presentation. The distinction should follow meaning as well as performance.

How to test whether lazy loading is helping

Testing should combine browser tooling, field observations, and human review. No single metric fully describes the experience.

Inspect the network sequence

Browser developer tools can show when an image or iframe request begins. Compare the request timing of important first-view resources with resources farther down the page. An essential image that starts unusually late may be lazy loaded, difficult for the browser to discover, or competing with other work.

Review Largest Contentful Paint

If a hero image is the LCP element, examine whether the delay occurs during server response, resource discovery, download, decoding, or rendering. Removing lazy loading may help when request discovery is late, but it will not correct an oversized file, slow server, or render-blocking dependency by itself.

Test scrolling behavior

Scroll at different speeds on both fast and constrained connections. Images should generally arrive before the user needs them without requiring every off-screen resource to be downloaded during the initial load.

Test representative devices and layouts

Desktop testing alone can conceal mobile problems. Review narrow and wide layouts, tall and short screens, slower hardware, and text enlargement. Responsive changes may alter which resources are initially visible.

Use real-user data when available

Laboratory tests provide controlled diagnostics. Real-user measurements show how the page behaves across varied devices, networks, and usage patterns. The two forms of evidence are complementary rather than interchangeable.

A balanced loading pattern

For many pages, a durable implementation follows a straightforward pattern:

• load the primary visible image normally;
• reserve its layout space with intrinsic dimensions;
• use responsive image markup to avoid transferring an unnecessarily large file;
• lazy load images and embeds positioned farther down the page;
• avoid initializing expensive third-party media before it is useful;
• apply priority hints only when testing supports them; and
• review the complete visual sequence on representative devices.

This is not a fixed formula. A text-focused page, image gallery, product page, news article, and web application each establish different priorities. The loading strategy should reflect the experience the page is meant to provide.

Frequently asked questions

Should every image below the fold use lazy loading?

No. Below-the-fold placement is a useful starting signal, not a complete decision rule. An image located just beyond the initial viewport may be encountered almost immediately, especially on a tall screen or during fast scrolling. Consider its distance from the viewport, file size, purpose, and behavior across responsive layouts.

Should a hero image be lazy loaded?

Usually not when the hero image is visible immediately or is likely to become the Largest Contentful Paint element. Delaying its request can postpone an important part of the first view. Decorative or nonessential hero-area imagery may require a different assessment.

Does loading="eager" make an image high priority?

Not necessarily. Eager loading tells the browser not to defer the image through lazy-loading behavior, but it does not automatically make that image the browser’s highest-priority request. The browser still considers document order, resource type, discovery timing, priority hints, and other page activity.

Can lazy loading improve performance while making a page feel slower?

Yes. Lazy loading may reduce initial network activity while delaying content the user expects to see. This is why measured efficiency and perceived responsiveness should be evaluated together.