Add Dimensions to Images: Stop Layout Shift (CLS)

What "Add dimensions to images" actually flags

Your audit tripped this check because at least one <img> on the page ships without a width and height attribute (or the CSS equivalent). When the browser meets an image with no declared size, it has no idea how much space to reserve, so it lays the page out as if the image were zero pixels tall, then yanks everything downward the instant the file arrives. That yank is a layout shift, and it feeds straight into your Cumulative Layout Shift (CLS) score.

The stakes: CLS is a ranking-relevant Core Web Vital, and layout shift is the metric users feel most viscerally. Nobody rage-quits faster than the reader who taps a button that jumps out from under their thumb because a header image finally loaded.

A real failing example (and the fix)

Here is the pattern the check hates. No dimensions anywhere, so the browser reserves no vertical space:

<!-- Reserves 0px height until the file downloads, then jolts the page -->
<img src="/uploads/hero-banner.jpg" alt="Product hero">

<figure>
  <img src="/uploads/author.png" alt="Author photo">
</figure>

The fix is boring and permanent: put the image's intrinsic pixel dimensions in the markup. The browser computes the aspect ratio from those two numbers and reserves the correct box before a single byte of the image arrives.

<!-- Box is reserved instantly; zero shift on load -->
<img src="/uploads/hero-banner.jpg" alt="Product hero"
     width="1600" height="900">

<figure>
  <img src="/uploads/author.png" alt="Author photo"
     width="240" height="240">
</figure>

Key point people miss: the numbers are the intrinsic file dimensions, not the display size. Your CSS can still stretch or shrink the image responsively. Add this one rule so the height scales with the width instead of locking to the attribute value:

img {
  height: auto;      /* let height track the responsive width   */
  max-width: 100%;   /* never overflow its container            */
}

With width/height present, modern browsers derive aspect-ratio automatically, so the reserved box stays correct at every viewport width.

Why the attributes work: the aspect-ratio trick

Modern browsers turned width and height attributes into something smarter than fixed pixels. When both are present, the browser computes an internal aspect-ratio from them and uses it to reserve the correct box the instant it parses the tag, before the image file has downloaded at all. So an image declared width="1600" height="900" reserves a 16:9 slot immediately, and your height: auto CSS lets that slot scale fluidly with the column width. The result is the best of both: a placeholder that is exactly the right shape, and an image that still stretches responsively. Leave the attributes off and the browser has no ratio to work with, so it reserves nothing and pays for it with a shift the moment the bytes arrive.

Attribute vs. CSS vs. missing: what the browser does

How to detect it on your own site

1. Lighthouse (Chrome DevTools): open DevTools, run a Lighthouse Performance audit, and look under diagnostics for "Image elements do not have explicit width and height." It lists the exact offending elements.
2. PageSpeed Insights: paste your URL at pagespeed.web.dev. The same audit appears, plus real-user CLS from the field (CrUX) so you know whether shifts are actually hurting visitors, not just the lab test.
3. DevTools Performance panel: record a page load, then check the "Layout Shift" markers on the timeline. Click one and it highlights the element that moved, usually an image whose box appeared late.
4. WebPageTest: run a test and open the filmstrip. Frame-by-frame you can watch content jump when an unsized image resolves. The waterfall pins the exact request.

How to fix it, step by step

1. Pull the intrinsic pixel dimensions of every flagged image (any editor, or the file's Get Info / Properties panel).
2. Add matching width and height attributes to each <img> tag.
3. Add the global img { height: auto; max-width: 100%; } rule so responsive scaling still works.
4. For CSS background images, give the container an explicit height or an aspect-ratio so it holds its space.
5. On a CMS, fix it at the source: modern WordPress and most builders inject dimensions automatically, so the culprit is usually a hand-coded template, a page builder module, or an old post. Patch the template, not one post at a time.
6. Re-run Lighthouse and confirm CLS from images drops toward 0.

FAQ

Do width and height attributes force my image to a fixed size?

No, as long as you pair them with height: auto; max-width: 100%; in CSS. The attributes only tell the browser the aspect ratio up front; the CSS controls the actual rendered size.

What numbers do I put if I serve responsive images with srcset?

Use the intrinsic dimensions of the image referenced in the plain src fallback. All variants in a well-built srcset share the same aspect ratio, so one set of width/height reserves the right box for all of them.

Does this help Largest Contentful Paint too?

Indirectly. Reserving space keeps the layout stable, which stops your LCP element from being pushed around mid-load. For loading speed itself, see how to improve LCP.

What about lazy-loaded images below the fold?

They still need dimensions. A lazy image that loads on scroll will shift content just as badly, so keep the attributes. See defer offscreen images for doing lazy loading without introducing shift.

Is CLS really a ranking factor?

It is part of Core Web Vitals, which Google uses as a page experience signal. It rarely outweighs relevance, but between two comparable pages the stable one wins. Read the full CLS guide for the ranking context.