Storefront Speed Journal

Reviewed November 9, 2026

Lazy Loading Below the Fold: Where It Helps LCP and Where It Hurts

Add loading="lazy" to images below the fold, and never to the hero image or any image in the first viewport. Lazy loading defers below-fold images until the user scrolls near them, which frees bandwidth and main thread time for the hero. Put it on the hero and the browser delays the largest element on the page, which is exactly what LCP measures.

Lazy loading is a one-word fix that helps or hurts depending on where the image sits. Below the fold, it is free performance: the browser skips the image until the user scrolls near it, and the bandwidth goes to the hero instead. On the hero image, it is self-sabotage: the browser defers the largest element on the page, and LCP, which measures when that element renders, gets worse.

The mistake is applying it everywhere. A theme that adds loading="lazy" to every image, including the hero, trades a small saving on below-fold images for a large delay on the one image that decides the LCP score. The fix is not to remove lazy loading. It is to aim it.

How native lazy loading works

The loading="lazy" attribute tells the browser to defer an image until it is near the viewport, usually within a few hundred pixels. The browser handles the timing itself, loading the image as the user scrolls toward it. There is no JavaScript to write and no library to load, which is why it replaced the old JavaScript lazy loaders on most stores.

The savings are real for image-heavy pages. A collection page with forty product images loads the first few and defers the rest, which cuts the initial page weight dramatically. The user who never scrolls past the first screen never downloads the images below it, which is the correct outcome for a page that most visitors will not read to the bottom.

The cost is a small delay when the user scrolls fast. An image that enters the viewport takes a moment to load, and a fast scroller can outrun it. The browser's preload distance, a few hundred pixels, is designed to hide that delay, and for most scrolling speeds it does. The trade is worth it, because the alternative is loading forty images up front and delaying everything.

The hero image rule, and why it is absolute

The hero image is the largest contentful paint on most storefronts. LCP measures when it finishes rendering. A loading="lazy" attribute on the hero tells the browser to wait, and the wait is the delay. The LCP score gets worse by exactly the time the browser waited, and there is no upside, because the hero is in the first viewport and would have loaded anyway.

The same rule applies to any image in the first viewport: the logo, the announcement bar image, the first product image on a product page. If the user can see it without scrolling, it is not below the fold, and it should not be lazy loaded. The attribute belongs on images the user has to scroll to reach.

The fix for the hero is the opposite attribute: fetchpriority="high". That tells the browser to load the hero first, ahead of everything else, which is what LCP wants. Pair it with a preload for the hero image in the page head, and the browser starts fetching it before it even parses the image tag. Lazy load the rest, prioritize the hero, and the LCP improves from both directions.

Checking a theme that lazy loads everything

Audit the theme's image tags. Search the theme files for loading="lazy" and list every image that carries it. The hero, the logo and the first product image should not be on that list. If they are, remove the attribute from those images and add fetchpriority="high" to the hero.

Test with the network tab open. Load the page and watch the order: the hero image should be among the first requests, not somewhere in the middle after the below-fold images. If the hero loads late, something is still deferring it, and the LCP score will show it.

Measure LCP before and after the change, on a throttled connection. The improvement from fixing a lazy-loaded hero is often the largest single LCP gain available on a store, larger than image compression, larger than font optimization, because it removes a delay from the one element the metric measures. It is also the cheapest fix in the audit, which is why it should be first.

Related reading

For the background behind “Lazy Loading Below the Fold: Where It Helps LCP and Where It Hurts”, these earlier guides help: AVIF vs WebP for Hero Images: The Cheapest LCP Win on Shopify, Web Fonts and LCP: Why Your Theme's Fonts Delay the First Paint, and Why Is My Shopify Store Slow on Mobile but Fine on Desktop?.

Frequently asked questions

Should I lazy load the hero image?

No. The hero image is usually the largest contentful paint, and lazy loading it delays the element LCP measures. Use fetchpriority="high" on the hero instead, and lazy load only the images below the fold.

Does lazy loading help or hurt LCP?

It helps when applied to below-fold images, because it frees bandwidth and main thread time for the hero. It hurts when applied to the hero or any image in the first viewport. Aim it at the images the user has to scroll to reach.

What is fetchpriority and when should I use it?

The fetchpriority attribute tells the browser which resource to load first. Set fetchpriority="high" on the hero image so the browser fetches it ahead of everything else. Pair it with a preload in the page head for the fastest result.

How far below the fold should lazy loading start?

Any image the user cannot see without scrolling is a candidate. The browser loads lazy images when they come within a few hundred pixels of the viewport, so the delay is hidden for normal scrolling speeds. Images in the first viewport should load normally, not lazily.