loading lazy vs eager on 1,677 homepage images, and the 9 sites that defer the first one

FIELD TEST · 2026-08-22 · 27 homepages · 1,677 images · single crawl

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-22 with a browser user agent. Every <img> in the delivered HTML was recorded in document order with its loading, fetchpriority and decoding attributes.

The loading lazy vs eager split across 1,677 images is not close: 1,123 are marked lazy, 133 eager, and 421 carry no loading attribute at all. On nine of the 27 homepages the very first image in the document is the one marked lazy — which Google's own performance guidance tells you not to do, with a caveat we will get to.

How we measured it

One HTTP request per site, no rendering, no retries. The inclusion rule was fixed before the run: status 200, body at least 10,000 bytes, body containing <body. Three of the 30 failed it — stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 27 homepages.

Document order is not paint order. We recorded which <img> comes first in the HTML, not which element ends up largest on screen. Those are different things, and the gap between them is the most important part of this post.

The loading lazy vs eager numbers

Two thirds of these images defer. A quarter say nothing, which per MDN means eager, since that is the default value of the attribute.

Three sites use the attribute on everything: developer.mozilla.org (1 of 1), www.netlify.com (23 of 23) and github.com (24 of 24) mark every image lazy. Three use it on nothing: www.canva.com ships 26 images with no loading attribute anywhere, and Hacker News and Wikipedia ship three and one respectively, also bare.

Cloudflare is the panel's inverse. Of its 66 images, 64 are explicitly eager, one is lazy, one is bare — and the first one carries fetchpriority="high".

What Google says about the first image

Two pages on web.dev say the same thing at different volumes. From "Browser-level image lazy loading for the web", last updated 2024-08-13 and read 2026-08-22: "Caution: Don't lazy-load images that are likely to be in-viewport when the page loads, especially LCP images." The same page adds that for images visible on first load "use the browser's default eager loading so they can be available right away".

"Optimize Largest Contentful Paint", last updated 2025-03-31 and read the same day, drops the hedge: "Warning: Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP." It also names the tool for the opposite case — if an image matters, "use Fetch Priority with fetchpriority="high"".

Lazy is a decision about what the reader will not see yet. The first image is the one they see first.

Nine homepages defer their first image

Here is what those first images actually are, which changes how the number reads.

Most of those are logos and icons — small, cheap, and not the largest paint on anyone's screen. Deferring them costs close to nothing. Railway's is the one that reads differently: it is a hero background, and the image right after it is the same hero in a different colour, marked loading="eager" fetchpriority="high". One theme is deferred, the other is rushed. That is a deliberate pair, not a mistake, and no attribute count would have told us.

Almost nobody uses fetch priority

Eight of 27 homepages set fetchpriority="high" on any image, and six of those eight set it exactly once.

The other 19 sites leave every image at the browser's default priority. There is also a small oddity worth naming: the first <img> in The Verge's homepage HTML is an analytics beacon pointing at google-analytics.com, inside a noscript fallback. Its second image is the lead story, and that one does carry fetchpriority="high". Six iframes appeared across the whole panel and none of them is lazy.

What this crawl cannot tell you

It cannot tell you which element is the LCP element on any of these pages. That is decided at paint time by viewport size, CSS, fonts and network conditions — none of which a single server-side fetch sees. So "nine homepages lazy-load their first image" is a statement about markup, and only a hypothesis about performance.

We did not measure LCP on any of these sites, and we are not going to pretend the attribute count is a substitute. Two of the nine could be losing half a second; seven of them are probably deferring a 4 KB logo and losing nothing.

A CSS background image can be the LCP element too, and this parse never saw one. If a site paints its hero from a stylesheet, its <img> attributes say nothing about how fast it renders.

What to do with your own images

The check takes two minutes and it is worth doing once per template, not once per image.

• Open the page, find what is largest in the first viewport, then look at that element's markup — not the first one in the file.
• Give that element fetchpriority="high" and no loading="lazy". Nineteen of these 27 sites have not set a priority on anything.
• Do not apply lazy loading to every image because a plugin offers to. Two thirds of this panel already does, and the default is not free at the top of the page.
• Do not assume a bare <img> is a bug. No attribute means eager, which is the right answer above the fold.

Reading the delivered markup instead of the rendered page is what the QueryWin checks do, and it is the same parse that produced the missing alt text survey from this panel. For how long these pages take to answer at all, there is the time to first byte survey, which found a bigger problem in the measurement than in the sites.

Common questions

How did you measure this?

One homepage request per site on 2026-08-22, browser user agent, no JavaScript execution. Every <img> in the delivered HTML was recorded in document order with its loading, fetchpriority and decoding attributes. No rendering, no retries.

What is the difference between loading lazy vs eager?

Eager fetches the image as the page loads regardless of where it sits; lazy defers it until it comes near the viewport. Per MDN, eager is the default, so an <img> with no loading attribute behaves as eager.

Should I lazy-load all my images?

No. Google's guidance is explicit that images likely to be in the first viewport, and the LCP image in particular, should not be deferred. Everything below the fold is fair game.

Does lazy loading hurt SEO?

Deferring the LCP image hurts Largest Contentful Paint, which is a documented Core Web Vitals metric. Whether that changes your position for any given search is not something this crawl measured, and we would not guess.