Lazy loading is supposed to make pages faster, yet it often makes the most important image load slower. If your Largest Contentful Paint (LCP) got worse after you added loading="lazy" everywhere, this article explains why and how to fix it. You will learn which images to lazy load, which to load eagerly, and how to decide in seconds.
What lazy loading actually does
The browser attribute loading="lazy" tells the browser to defer downloading an image until it is near the viewport. Native lazy loading is built into modern browsers and needs no JavaScript. The goal is to save bandwidth and speed up the initial load by skipping images the user may never scroll to.
The catch: the browser cannot start fetching a lazy image until it has calculated layout and decided the image is close enough to the viewport. That delay is fine for a footer logo. It is harmful for the big hero image at the top of the page.
Why lazy loading hurts your hero image
LCP measures when the largest visible element finishes rendering. On most landing pages that element is the hero image or a large banner. When you mark that image as lazy, you add an extra step before the download even begins. The browser must run layout first, then request the image. Those milliseconds push your LCP later.
The rule is simple. Images that are visible when the page first paints (above the fold) should never be lazy loaded. Everything reliably below the fold is a good candidate.
Eager, lazy, and the fetchpriority hint
- loading=”eager” (the default) downloads immediately. Use it for above-the-fold images.
- loading=”lazy” defers the download. Use it for below-the-fold images.
- fetchpriority=”high” tells the browser this image matters. Add it to your LCP image so it competes ahead of less important requests.
A real scenario
A client had a product page where LCP sat around 4.1 seconds on mobile. Their build tool applied loading="lazy" to every image, including the main product photo at the top. We changed one line: the primary image became loading="eager" with fetchpriority="high", and we kept lazy loading on the gallery thumbnails further down. LCP dropped to roughly 2.6 seconds on the same device and connection. Nothing else changed. The fix was deciding which single image mattered most and letting the browser fetch it without delay.
Common mistakes and how to fix them
- Lazy loading the hero image. Fix: load the first meaningful image eagerly. A blanket “lazy load all images” setting is the usual culprit.
- No width and height on images. Missing dimensions cause layout shift and can delay when the browser decides a lazy image is in view. Fix: always set
widthandheight(or use CSSaspect-ratio). - JavaScript lazy loading for above-the-fold content. Older libraries wait for scripts to run before showing images. Fix: prefer native
loading="lazy"and reserve JavaScript only where you need finer control. - Lazy loading tiny icons. Deferring a 2 KB icon adds request overhead for no real saving. Fix: only lazy load images heavy enough to matter, and that sit below the fold.
When to use each approach
| Image type | Recommended |
| Hero or LCP image | eager + fetchpriority high |
| Above-the-fold logo or icon | eager |
| Below-the-fold photos | lazy |
| Long gallery or feed images | lazy |
Action checklist
- Open your page and identify the single largest image visible on first load.
- Make sure that image uses
loading="eager"and addfetchpriority="high". - Apply
loading="lazy"to images that sit below the fold. - Set explicit
widthandheighton every image. - Re-measure LCP in a lab tool such as Lighthouse and on real devices.
Conclusion and next step
Lazy loading is a tool, not a default to apply everywhere. Load above-the-fold images eagerly, lazy load the rest, and mark your LCP image as high priority. Your next step: audit one important page today, fix the hero image, and compare LCP before and after.
FAQ
Does lazy loading improve Core Web Vitals?
It can improve total bytes and reduce work for below-the-fold images, but applying it to the hero image usually worsens LCP. Use it selectively.
Should I lazy load images inside an iframe?
Iframes support loading="lazy" too, and it is often worth it for embedded maps or videos below the fold, since those are heavy.
Is native lazy loading better than a JavaScript library?
For most sites, yes. Native lazy loading is simpler, needs no extra script, and is well supported in current browsers. Use a library only when you need custom thresholds or effects.
Why does my LCP image still load late even when eager?
Other high-priority requests may be competing for bandwidth. Adding fetchpriority="high" and preloading the image URL can help the browser prioritize it.
References
- MDN Web Docs: the
loadingattribute for images. - web.dev by Google: guidance on Largest Contentful Paint and image priority.