Images Without width and height: Layout Shift Measured

The question: how much layout shift do images without width and height really cause, and do the two common fixes (HTML attributes, or CSS aspect-ratio) remove it completely? We loaded one article page in three versions, five times each on a phone and a desktop viewport, and read Cumulative Layout Shift (CLS) straight from Chrome’s own layout-shift entries.

The test page

The page is a short article with three 16:9 photos (CC0, WebP, 1024 × 576) placed between paragraphs, in a responsive column (max-width: 100%). The three variants differ only in how the image box is described:

1. No dimensions: <img src="..." alt="...">.
2. width and height attributes: width="1024" height="576", with height: auto in CSS so the image still scales with the column.
3. CSS aspect-ratio: no attributes, aspect-ratio: 16 / 9; width: 100%; height: auto.

Layout shift only happens when text is painted before the images arrive, which is common on real sites where images come from a slower server or CDN. To make that situation repeatable, our local test server holds each image response for 1.5 seconds. Pages were loaded in fresh Chrome 154 profiles on our slow mobile profile (150 ms latency, 1.6 Mbit/s, 4× CPU), as described in the methodology.

What did not work at first: in our first run the images were served without delay, and on the mobile viewport they arrived before the first paint, so every variant scored a CLS of 0 on mobile. That result was true but useless: it only showed that fast images hide the problem. We added the controlled delay and repeated the test.

Results

Without dimensions, the page’s median CLS was 0.1495 on mobile and 0.0845 on desktop. Google’s Core Web Vitals guidance treats 0.1 or less as “good”, so three ordinary images pushed the mobile page into “needs improvement” on their own. The mobile score is higher because the narrow column makes each image taller relative to the screen, so the text below moves further when it arrives.

Both fixes brought the median CLS to exactly 0 on both viewports. The screenshots above, taken 1.2 seconds after navigation, show why: with dimensions, the browser leaves an empty 16:9 box where each image will go; without them, the text is laid out as if the images did not exist and is pushed down later.

Largest Contentful Paint was the same for all three variants (about 2.36 seconds, set by the 1.5-second image delay). Reserving space does not make the page load faster; it makes it stop jumping.

Attributes or aspect-ratio?

Both worked equally well here. We still recommend the HTML attributes as the default, for practical reasons:

• Browsers derive the aspect ratio from width and height automatically, so the attributes work without any extra CSS apart from height: auto.
• WordPress and most CMSs already output them. Check that your theme does not remove them or override height with a fixed value.
• CSS aspect-ratio is useful when one CSS rule must cover many images of the same shape, or for containers (such as a video embed or a background image) that have no intrinsic size.

One mistake to avoid: setting width and height attributes without height: auto in a responsive layout. The image is then squeezed to the column width but keeps its full attribute height, and looks stretched. We made exactly this mistake in an early version of our own test pages and had to re-run several experiments.

Practical conclusion

• Give every content image width and height attributes that match its real aspect ratio, and keep height: auto in CSS.
• Use aspect-ratio for boxes without intrinsic dimensions.
• Test layout shift with slow images. A fast local connection can hide the problem completely, as our first run did.

How this connects to our other tests

Reserving space matters most when images arrive late, and several of our other tests show when that happens. Lazy-loaded images below the fold arrive while the reader is already scrolling, so they always need dimensions (lazy-loading test). Art-directed images can switch to a different aspect ratio on phones, which is why each <source> needs its own width and height (art direction test). And a server that is slow to deliver images, like the AVIF files served with the wrong content type in our AVIF upload test, makes late arrival more likely, not less.

Repeat this test on your own images

To measure layout shift on your own page, open Chrome DevTools, go to the Performance panel, enable a slow network profile and record a reload: layout shifts are listed with the elements that moved. For a quick number, paste this into the console before reloading with the Preserve log option, or run it from a bookmarklet:

let cls = 0;
new PerformanceObserver(l => { for (const e of l.getEntries()) if (!e.hadRecentInput) cls += e.value; console.log('CLS', cls.toFixed(4)); })
  .observe({ type: 'layout-shift', buffered: true });

To find the culprits, search your templates for <img tags without width and height; in WordPress, check images that the theme outputs outside the post content, such as headers, logos and related-post thumbnails, because WordPress adds missing dimensions to images inside the post content, while images hard-coded in templates are up to the theme. Remember that a fast connection can hide the problem completely, as our first run showed, so test with throttling or with slow images. Our test pages and the delayed-image server are in build_pages.mjs and server.mjs.

Limitations

A single article layout with three images, one browser and an artificial 1.5-second image delay. The size of the shift depends on image height and position; images at the very top of a page, ads and web fonts cause shifts of their own that this test does not include.

Data and files

Download loading-cls.csv (6 rows, 0.6 KB) · Method: testing methodology. Photos: image credits.