Performance
Lazy loading: when it makes performance worse
Putting loading="lazy" on the image above the fold pushes LCP back. Real measurements, a practical rule and the cases where lazy loading costs.
Key points
- Lazy loading makes a page worse when it defers the image that would become the LCP.
- On the /components page measured on 1 November 2026, 52 of 60 images were lazy and 8 had loaded without scrolling.
- If you cannot tell whether an image sits above the fold, do not mark it lazy.
Lazy loading makes a page worse when it hits the largest image on the first screen: the browser discovers it after layout, so LCP measures a wait that could have been avoided. Use it below the fold, never above.
Where lazy loading helps
It earns its place on everything the visitor cannot see at first paint: long card grids, galleries, preview iframes, images inside closed tabs. There the download does not touch LCP and saves bytes.
- Card grids that run past the second screen.
- Preview iframes and video players placed further down.
- Images inside tabs, accordions or modals that start closed.
Where it costs you
The LCP candidate is not always the banner. On a detail page it can be the first card, a large logo or a preview. When it sits above the fold, loading="lazy" takes away its head start.
The first line loads the image on the first screen at once and declares its priority. The second defers the download and keeps the dimensions, so it produces no layout shift.
The practical rule
If you cannot tell whether an image is above the fold, do not mark it lazy. One extra image costs a few KB; a worse LCP costs visits.
| Element | Attributes | Why |
|---|---|---|
| Image on the first screen | fetchpriority="high" | it is the LCP candidate |
| Card below the fold | loading="lazy" | off screen at first paint |
| Preview iframe | loading="lazy" | 60 KB nobody asked for |
The command to check it
npx playwright screenshot --viewport-size=390,844 --wait-for-timeout=3500 https://ui.eneawork.it/components shot.pngThe screenshot shows what a visitor sees after 3.5 seconds. Open it with the Network panel: the images never requested are the ones lazy loading held back.
The limitation
The measurement covers one page, one viewport and one connection. On another template or a slow network the numbers move, and a lazy image becomes the LCP when everything else is smaller than it.
Where to continue
The EneUI catalogue indexes 111,985 components and 1,556 blocks with previews. The record interactive image accordion loads several images: check the attributes before you install it. For layout shift read images without dimensions, for the thresholds Core Web Vitals, for the measured comparison React libraries 2026.
Frequently asked questions
When should I avoid loading=lazy?
On the largest image visible at first load and on every image above the fold. There the immediate download is what makes LCP fast.
Does lazy loading hurt SEO?
No, as long as the images stay in the DOM and crawlers can see them. It hurts indirectly when it makes LCP worse, which is a page experience signal with less weight than relevance.
Is loading=lazy safe on an iframe?
Yes, modern browsers support it and it pays off on players and off-screen previews. In this repository the attribute appears in 8 files, one iframe included.
Lazy loading or content-visibility?
They solve different problems: lazy defers the download of a resource, content-visibility defers the rendering of a section. You can combine them, but neither fixes the LCP image.
How do I check which images are lazy?
Open the Elements panel and look for the attribute, or count requests in the Network panel before and after a scroll. The difference is what lazy loading held back.