srcset on 1,664 homepage images: 608 carry one, 811 declare no size at all

FIELD TEST · 2026-08-27 · 26 homepages · 1,664 images · single crawl · raw HTML only

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-27 with a browser user agent, no rendering. We read every <img> element in the raw HTML and recorded its src, whether srcset and sizes were present, the descriptor type inside the srcset, the width and height attributes, and loading.

Across 1,664 images on 26 homepages, 608 carry a srcset and 811 carry neither a width nor a height. Those are two different jobs and they get done by different sites: the srcset decides which file gets downloaded, the two dimension attributes decide whether the page stops jumping while it loads. Six sites do the first and skip the second. Three do the reverse.

How we measured it

One HTTP request per site, no rendering, no retries. Inclusion was fixed before the run: final status 200, decoded body at least 10,000 bytes, body containing <body. Four of the 30 failed — www.canva.com returned 429, stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 26.

Attributes were read as boolean by presence, never by value, so width="" counts as declared and an absent attribute does not. Descriptor type was recomputed a second time straight from the saved bytes with a regular expression, because the parser only told us a srcset existed, not what was inside it. Both passes agree.

# Same three counts on your own page
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ > page.html
grep -o '<img[^>]*>' page.html | wc -l                 # total
grep -o '<img[^>]*srcset=[^>]*>' page.html | wc -l     # with srcset
grep -o '<img[^>]*>' page.html | grep -c 'width=.*height=' 

What we did not measure: which file a real browser actually picked. That depends on viewport, pixel density and the CSS that had already been applied, none of which a single non-rendering fetch can see. Everything here is what the markup offers a browser, not what a browser chose.

srcset is on 37% of images, and the two descriptor types split unevenly

Of 1,664 images, 608 carry a srcset. Twenty of 26 sites use it at least once, and six use it zero times. Inside those 608, the width descriptor beats the pixel-density descriptor by more than two to one.

The two descriptors are not interchangeable, and MDN's img reference, read on 2026-08-27, is direct about why: a width descriptor "must match the intrinsic width of the referenced image", and "when a srcset contains 'w' descriptors, the browser uses those descriptors together with the sizes attribute to pick a resource". The pixel-density descriptor needs no sizes at all. Same page: "It is incorrect to mix width descriptors and pixel density descriptors in the same srcset attribute." No image in this sample mixes them.

Coverage per site is close to all-or-nothing. The Verge ships a srcset on 107 of 108 images, Ars Technica on 59 of 61, Stripe on 29 of 30. Discord ships one on 17 of 171, Webflow on 1 of 168. This is a build-pipeline setting, not a per-image decision, and it shows.

811 images declare no size, and three news sites account for 239 of them

Just under half the sample — 811 of 1,664 — carries neither a width nor a height attribute. Another 51 carry exactly one of the two, which reserves nothing.

MDN states the consequence plainly: "Including height and width enables the aspect ratio of the image to be calculated by the browser prior to the image being loaded. This aspect ratio is used to reserve the space needed to display the image, reducing or even preventing a layout shift when the image is downloaded and painted to the screen."

Three sites carry zero dimension attributes across every image they ship — www.bbc.com (134 images), www.nytimes.com (55) and www.wired.com (50). That is 239 images, and all three are news sites running an image component that sets the box in CSS instead. Seven sites go the other way and declare both on every single image: nextjs.org, vercel.com, www.notion.com, www.netlify.com, developer.mozilla.org, news.ycombinator.com and www.wikipedia.org.

Whether the three news sites actually shift layout is not something a markup crawl can answer — a CSS aspect-ratio box does the same job, and we did not verify any of them in a browser. What the crawl can say is that the cheap declaration is missing on 862 images.

sizes=auto appears on 106 images, and all 106 are lazy

The sizes="auto" keyword is newer than most of this markup, and exactly two sites use it: Ars Technica on 54 images and TechCrunch on 52. Every one of the 106 also carries loading="lazy", which is the condition MDN attaches to it: "This is only valid when combined with loading='lazy', as the page is expected to already have CSS and other layout information by the time the image loads."

That is a clean result, and it surprised us. Two sites adopted a fairly obscure keyword and neither of them got the pairing wrong. The related mistake — a sizes attribute with no srcset to apply it to, which does nothing — appears zero times in 1,664 images. The one real gap is smaller than expected too: of the 485 images using width descriptors, 21 omit sizes, and those 21 fall back to a source size of 100vw.

117 img elements arrive with no src at all

This is the finding that matters most for anything reading your page without running JavaScript. Across four sites, 117 <img> elements ship with no src attribute: Slack 69, Wired 24, The New York Times 23, Vercel 1. Slack and Wired put the real URL in data-src instead, which a script swaps in later.

None of those 117 carries a srcset either. To a client that reads the delivered HTML and stops, they are empty elements. Google's image documentation asks for the opposite: "We recommend that you always specify a fallback URL using the src attribute."

A srcset decides which file a browser downloads. A missing src decides whether anything else can see the image at all.

What this means for you

Three checks, in the order they pay off. The first costs nothing and fixes the largest number in this report.

1. Put width and height on every image, matching the file's intrinsic pixels. It is two attributes and it removes the layout shift before any CSS loads.
2. If you ship a srcset with w descriptors, ship a sizes to go with it, or accept 100vw. If your image is a fixed-size logo, use x descriptors instead and skip sizes entirely.
3. Keep a real src on every image even when a script will replace it. That is the only one of the three that is invisible to your own browser and visible to everything else.

The method behind all three, including what Google says it reads from an image and what it ignores, is image seo best practices. The loading attribute on this same panel was counted earlier in loading lazy versus eager on 1,677 images, and the wider question of what survives when nothing runs is whether AI can crawl JavaScript. To see what an engine receives from your own pages, see how QueryWin works.

Common questions

How did you measure this?

One request per homepage on 2026-08-27 with a browser user agent, bodies written to disk, img elements read by an HTML parser, then descriptor types recounted directly from the saved bytes so the two passes could be compared.

What does srcset actually do?

It offers the browser several files for the same image and lets it choose one. With w descriptors the choice depends on the sizes attribute and the device; with x descriptors it depends only on pixel density. The browser picks; you cannot.

Do I need sizes with srcset?

Only with width descriptors. MDN puts it as a spec requirement: "The sizes attribute only be present when srcset uses width descriptors." With pixel-density descriptors sizes is ignored, and in this sample nobody wrote one anyway.

Does srcset help SEO?

Not on its own. Google's image documentation describes it as a delivery technique — "The srcset attribute allows specifying different versions of the same image, specifically for different screen sizes" — and asks for a fallback src alongside it. The measurable effect is on bytes and on layout, not on how the image is understood.

Why is picture used by so few sites?

Seven of 26 use it, for 183 images and 181 <source> elements. It solves a different problem from srcset: different files rather than different sizes of one file, usually for format or for art direction. Wired accounts for 85 of the 181 source elements by itself.