Lazy Loading or Eager Loading: Which for LCP?

Your hero image is lazy loaded, your LCP is stuck above 2.5 seconds, and every speed tool you run tells you to "defer offscreen images." So you did. And the score got worse. That's not a bug in the tools — it's a conflict between two pieces of advice that both sound right: lazy load images to save bandwidth, and load the biggest image fast to pass Largest Contentful Paint (LCP). You can't do both to the same image.

Here's the decision rule, then how to apply it.

The short answer

Lazy load images that are below the fold. Load the image that is your LCP element eagerly, and tell the browser it's the priority.

That's it. The mistake almost everyone makes is applying a blanket loading="lazy" to every <img> on the page — usually via a WordPress plugin, a Shopify theme setting, or a framework default — which catches the one image that must not be lazy loaded.

Why lazy loading hurts LCP

loading="lazy" tells the browser: don't fetch this until it's close to the viewport. That's exactly what you want for the twelfth product photo. It's the opposite of what you want for the image a visitor sees in the first half-second.

The browser has to run layout, work out that the image is near the viewport, then start the request. On a fast connection you lose a few hundred milliseconds. On a slow mobile connection you lose the request slot entirely — the browser could have been downloading that image while it parsed your CSS and JavaScript, but instead it waited.

Since LCP measures when the largest content element finishes rendering, and on most marketing pages that element is a hero image, a headline with a big background, or a product photo, delaying that fetch delays the metric directly.

When to lazy load

Use loading="lazy" for:

Images far down the page: footer logos, testimonial avatars, gallery items, related-product grids.
Anything inside a carousel or accordion that isn't visible on load.
Long blog posts with many inline images.
Third-party embeds you've replaced with a static preview image (map placeholders, video thumbnails).

Lazy loading still earns its keep. It reduces bytes on first load, frees bandwidth for the assets that matter, and improves data usage for mobile visitors. It's just not a universal default.

When to eager load

Eager load — the browser default — for:

The hero image or banner.
The first product image on a product page.
A logo or above-the-fold illustration that is the LCP element.
Any image visible in the initial viewport, on both desktop and mobile widths.

If you're not sure which image is your LCP element, don't guess. Open your page in Chrome DevTools, go to the Performance panel, and look for the LCP marker in the timings track — it names the element. You can also check the Core Web Vitals report in Search Console for field data, though that's aggregated and won't name the node. For a quick page-level read, run a free audit and look at what the tool flags as your largest paint.

How to prioritize the LCP image properly

Removing loading="lazy" is step one. Step two is making sure the browser starts that fetch as early as possible.

Add fetchpriority="high" to the LCP image. This is a hint that raises the image's priority in the browser's fetch queue. Use it on one image per page — if you mark everything high, nothing is high.
Never add fetchpriority="low" or loading="lazy" to the LCP image, even if a plugin or framework does it for you. Check the rendered HTML, not the settings screen.
Preload it with <link rel="preload" as="image" href="..." fetchpriority="high"> in the <head> if the image is referenced from CSS (a background image) rather than an <img> tag. Preload is easy to over-use; keep it to the LCP image and maybe a critical font.
Don't lazy load the image via JavaScript. Libraries that swap a placeholder for the real source on scroll add a request round-trip. Native loading attributes are handled by the browser and are usually faster.
Set explicit width and height on the image so the browser reserves space. This protects Cumulative Layout Shift (CLS) — a different metric, but one that often breaks at the same time as LCP when you're editing image markup.

A quick pre-flight check before you ship

Run this on any template you touch:

Load the page with the network throttled to Slow 4G in DevTools.
Find the LCP element in the Performance panel.
Confirm its HTML has no loading="lazy".
Confirm it has fetchpriority="high".
Confirm the image is served in a modern format and at a sensible size — a 2400px image scaled down to 600px wastes the same bandwidth you were trying to save.
Check the mobile breakpoint separately. A hero that's above the fold on desktop can sit below it on mobile, and vice versa.

That last point catches a lot of people. If your mobile hero is a different image from your desktop hero, both need the eager treatment.

The one-line rule to remember

Lazy loading is a bandwidth optimization for images the visitor can't see yet. Eager loading plus fetchpriority="high" is a speed optimization for the image they see first. They're not competing strategies — they're two settings for two different jobs, and mixing them up is one of the most common reasons a page fails Core Web Vitals after an otherwise sensible optimization pass.

If your LCP is still poor after fixing the loading attributes, the bottleneck is usually somewhere else — render-blocking CSS, a slow server response, or a third-party script. For a structured walkthrough of those, see the guides library.

More guides · Compare audit tools · Run a free website audit