width and height attributes on 25 homepages: half of 1,711 images ship neither

FIELD TEST · 2026-09-22 · 25 homepages · single crawl · <img> width/height attributes only

Sample and method: 30 homepages requested once on 22 September 2026 with a desktop Chrome user agent and no JavaScript execution. Five returned a challenge, a redirect or a shell page with no <img> at all and were dropped; the remaining 25 produced 1,711 <img> elements. Only the HTML width and height attributes are counted — CSS sizing is not.

Half the images on 25 busy homepages ship with no width and height attributes at all. Of 1,711 <img> elements parsed on 22 September 2026, 761 carried both attributes, 86 carried exactly one of the two, and 864 — 50.5% — carried neither. Three homepages declared a dimension on not one image on the page.

How we measured

We requested each homepage once, followed redirects, and parsed the returned HTML with a strict tag parser. No browser, no JavaScript, no rendering. The count is therefore a count of what the server sent, not of what a visitor ends up seeing: an image injected by client-side JavaScript is invisible to this method and is not counted at all.

The five dropped homepages are part of the result, not a footnote. Reddit, Medium, Stack Overflow, Canva and The New York Times returned a 403, a redirect loop or a JavaScript shell with zero <img> tags, so there was nothing to measure. A panel of 25 is smaller than the 27 we have used for other surveys on this site, and it is smaller for that reason only.

One definition matters for reading the table. An image "has both attributes" when the HTML literally contains a width attribute and a height attribute. It says nothing about whether the value is a sane pixel number — more on that below.

What we found

The spread is the finding. Six homepages declare dimensions on every single image. Three declare them on none. The rest sit somewhere in between, and the sites with the most images are not the sites that do best.

Three patterns sit under the totals. First, the six perfect scores — notion.com, mozilla.org, nextjs.org, vercel.com, netlify.com and wikipedia.org — are all sites whose images come from a component or a template, which sets the attributes once. Second, the three zero scores are not small sites: bbc.com shipped 136 images with no dimensions, wired.com 52, github.com 24. Third, 143 of the 1,711 images sit inside a <picture> element, and 615 carry a srcset — the responsive machinery and the explicit-dimension habit do not arrive together. Of the 615 images with a srcset, 202 (32.8%) have neither attribute.

Why width and height attributes matter

An image without a declared size occupies zero space until it loads, then shoves everything below it down. That movement is Cumulative Layout Shift, one of the three Core Web Vitals. Declaring width and height lets the browser reserve the right box before the bytes arrive, and the modern rule is that the attributes alone are enough — the browser derives the aspect ratio from them even when CSS overrides the rendered size.

This is a layout property, not a ranking trick. We are not claiming that adding the attributes raises a position, and nothing in this measurement tests that. What it does mean is that a page can be perfectly fast and still move under a reader's thumb, and the cause is usually one line of HTML.

There is a second, quieter cost. Size is not shape. An image that declares width="1200" height="630" has told the browser its ratio. An image that declares width="Auto" has told it nothing, and still counts as "has both attributes" in a naive audit — including, we suspect, more than one commercial one.

What this means for you

You can check your own site in about a minute, because the rule is mechanical. Open the page, view source, and search for <img. Every one that lacks either attribute is a box the browser cannot reserve.

• Put width and height on every <img>, using the image file's real pixel dimensions.
• Let CSS size the image on screen; the attributes only feed the aspect ratio.
• Fix the ones inside <picture> and srcset too — they are the most likely to be missed.
• Do not write width="100%" or width="Auto" to satisfy an audit. We counted 102 attribute values across the panel that are not integers, and none of them reserves a box.
• Do not set only one of the two. We counted 86 images with exactly one, and half a ratio is no ratio.

If you are prioritising, start with the images above the fold, because that is where shift is visible and where the metric is scored. Images far down the page still matter, but they are not what a reader notices.

Common questions

Do width and height attributes still matter if CSS sets the size?

Yes, and that is the case they are designed for. CSS decides how large the image is drawn; the attributes tell the browser the ratio before the file loads, so it can reserve the box. Without them there is no ratio to reserve.

How did you measure this?

One request per homepage on 22 September 2026, desktop Chrome user agent, no JavaScript, followed redirects, parsed with a strict HTML tag parser. We counted the presence of the width and height attributes on each <img> and did not evaluate whether the value was valid.

Does a missing width or height hurt rankings?

We did not measure that and will not claim it. The attribute's documented job is layout stability, which feeds Cumulative Layout Shift, which is a Core Web Vital. Whether that turns into a position change on your site is a separate question, and it is the one does page speed affect SEO takes on.

Why is the panel 25 and not 27 like your other surveys?

Because five of the 30 homepages returned a challenge, a redirect or a JavaScript shell with no images in the HTML at all. We could have padded the count by measuring a rendered page instead, but that would have changed the method mid-survey, so we dropped them and said so.

Are these the same images your alt text survey counted?

Different crawl, different day, and a different question. That survey asked whether each image carried alt text; this one asks whether it carried a declared size, and the two lists are not directly comparable.

The boundary to keep in mind: this measures the HTML a server sends, not what a browser finally paints. Images added by JavaScript, background images set in CSS, and anything a CDN rewrites on the way out are all outside the count. For the images that are in it, the honest summary is that half of them leave the browser to guess, and the fix is one attribute pair. Turning that fix into a change that actually gets published is the part QueryWin works on, and the loading half of the same story is in lazy versus eager across 1,677 homepage images and the alt text survey.