Why Image Dimensions Matter Again

For years, web performance advocates have urged developers to include width and height attributes on <img> elements. The reasoning was straightforward: if the browser knows the image's dimensions from the HTML alone, it can reserve the correct amount of space before the image file arrives. Without those attributes, the page renders, then jumps as each image downloads and the layout recalculates.

These shifts are more than an annoyance. A user who has started reading can be thrown off mid-paragraph, and the browser has to do extra work recalculating the layout for every image that arrives. On pages with many images — a gallery with 100 images, for example — the CPU cost is substantial, especially on lower-end devices or slow connections where images arrive separately. The impact on load time is noticeable.

But here's the dirty secret that wasn't widely known: until recently, adding width and height attributes didn't actually help in many common cases. Browsers often ignored those attributes whenever CSS was used to constrain the image's display size. That has changed, and the fix is now rolling out across major browsers.

The CSS Conflict

The core problem was an interaction between HTML attributes and CSS. Suppose you set both width and height on the image tag, then use CSS to limit the image's display width:

img {
  max-width: 100%;
}

This overrides the width attribute but not the height, breaking the aspect ratio and stretching the image. The traditional fix is straightforward:

img {
  max-width: 100%;
  height: auto;
}

Adding height: auto overrides the HTML height attribute too, letting the browser calculate the correct height from the width constraint and the image's intrinsic aspect ratio.

But this combination created a new problem. When CSS is used to make images responsive — for example, with a rule like max-width: 100% — the browser needs the image file itself to determine the height. The width and height attributes in the HTML were effectively ignored for layout purposes. So a page like this:

<style>
img {
  max-width: 100%;
  height: auto;
}
</style>
<h1>Your title</h1>
<p>Introductory paragraph.</p>
<img src="hero_image.jpg" alt=""
  height="500" width="500">
<p>Lorem ipsum dolor sit amet, consectetur…</p>

still caused layout shifts, because the CSS's height: auto meant the browser had to wait for the image to know how tall it should be.

The result was that specifying dimensions in HTML only worked when the image was shown at full size with no CSS resizing. Any page that constrained images responsively — which is to say, virtually every site on mobile — was back to the original problem. And those mobile users, often on slower networks and less powerful devices, are exactly the people most affected by layout shifts.

Given these limitations, it's no surprise that many sites don't bother with dimensions at all. Even Lighthouse, Google's auditing tool, doesn't flag their absence — though discussions about revisiting that are underway.

The Old Workarounds

Developers who wanted to avoid layout shifts with responsive images had to resort to hacks. The best known is the padding-bottom technique, which exploits the fact that percentage padding is calculated relative to the container's width. For a 16:9 image:

.img-container {
  position: relative;
  padding-bottom: 56.25%; /* 16:9 ratio */
  height: 0;
  overflow: hidden;
}

.img-container img {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

This preserves the aspect ratio and reserves space, but it has serious downsides:

  • Each image ratio requires a hard-coded percentage (56.25% in this case), so the CSS must be customized per image.
  • The technique is fragile — forgetting or removing one line breaks the entire layout.
  • Every image needs to be wrapped in an extra container element.

It's a hack, not a solution. But it was the only way to get stable layouts with responsive images given the browser behavior of the time.

Closing The Aspect-Ratio Gap

The layout shift problem that occurs when images load without reserved space has been approached from multiple angles. The CSS Working Group proposed a dedicated aspect-ratio property to make the math explicit:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 16/9;
}

That handles the complexity problem cleanly for cases where dimensions are predictable — video embeds with standardized ratios are a good fit. For images, whose dimensions vary widely, it still leaves the per-image authoring burden in place and does nothing to guarantee developers will remember to apply it.

Another proposal from the Web Incubator Community Group (WICG) took a different route with an HTML attribute:

<img intrinsicsize="400x400" style="width: 100%">

An attribute can be set per image and is easy to add, but any new mechanism suffers from the adoption problem: developers already have a familiar way to declare image dimensions via width and height attributes, even if they often skip it. A solution that demands learning something new is unlikely to gain traction.

Reusing The Attributes Already There

The turning point was a proposal from Jen Simmons and fantasai that avoided introducing any new markup:

<style>
  img {
    width: 100%;
    height: auto;
    aspect-ratio: attr(width) / attr(height);
  } 
</style>
<img src="hero_image.jpg" alt="" width="500" height="500">

The idea leverages the existing width and height HTML attributes and feeds them through the CSS attr() function into an aspect-ratio calculation. The attr() function has long worked for the content property in all browsers, but general support for reading arbitrary attribute values into other CSS properties is not available yet.

If attr() can read those two well-known attributes, the ratio can be computed automatically for a wide range of existing markup. The calculation succeeds when all of these hold:

  • height is present on the HTML element;
  • width is present on the HTML element;
  • either height or width is set in CSS, including responsive values like max-width: 100%;;
  • the other dimension is auto in CSS.

If any one of those conditions is missing, the ratio cannot be derived and the old behavior of waiting for the image download applies.

That compatibility with existing markup is the key advantage. It gives browsers a way to remove layout shifts without asking developers to change their code at all.

Browser-Led Rollout

The proposal included a further twist: rather than waiting for site authors to adopt new CSS, browsers could place the one-line aspect-ratio rule in their user-agent stylesheet — the default layer where browser-defined styles like heading sizes live. Any author CSS overrides it, but sites that do nothing would still benefit automatically.

That approach depends on both the extended attr() support and the finalized aspect-ratio property, neither of which was ready. The same logic can, however, be implemented directly in rendering engines, which is the path Firefox took in an experiment and then enabled by default in Firefox 71. Chrome followed with its own implementation in Chrome 79, covering Chromium-based browsers such as Edge, Opera and Brave as well. Apple added the feature to its Safari Technology Preview in January 2020, signalling that the last major browser would soon close the gap.

Handling Bad Markup

Behavior changes carry backward-compatibility risks, and this one surfaced a real edge case during Firefox's experimentation: pages that had incorrect width or height attribute values. Previously, author CSS would override those mistakes. With the new calculation, the wrong values would be used for layout when the CSS dimension was auto, producing squished or stretched images until the actual file loaded.

That was an existing bug in some of those pages — any layout that forgot the matching auto rule was already broken. But shipping a feature that makes matters more visible still counts as a regression. The resolution: once the image loads, its actual intrinsic aspect ratio overrides the calculated one. The pre-load space might be imperfect, but it is usually much closer to correct than nothing at all, and the final display of the image remains unchanged.

Known Limitations

The fix is far from universal. Three areas remain problematic.

Art Direction

When responsive markup serves different images at different viewport sizes — a wide crop on desktop and a square one on mobile — the single set of width and height attributes applies only to the fallback <img> element, not to each <srcset> candidate:

<picture>
  <source media="(min-width: 327px)"
     type="image/jpeg">
  <source type="image/jpeg"
    >
  <img src="hero_800x400.jpg" alt=""
     width="800" height="400">
</picture>

Channeling each candidate's dimensions into the calculation was proposed for the HTML spec and landed in Chrome 90, but for browsers without that support, art-directed images still trigger layout shift.

Lazy Loading

The feature pairs naturally with lazy loading, since reserving space before an image loads prevents the shift when it eventually appears. Native lazy loading uses the standard <img> element with a src and works inside <picture>:

<img src="hero_800x400.jpg" alt=""
  width="800" height="400">

Early versions of Chrome's native lazy loading, however, did not apply the ratio-based space reservation. A bug was filed, and it was fixed in Chrome 83. Custom lazy-loading implementations can still bypass the benefit altogether if they use a src-less image or an entirely different element to hold the off-screen content until needed.

Non-Image Elements

Implementation so far is limited to <img>. Videos, iframes and object embeds have the same layout-shift problem, and extending the behavior to them has been proposed but not yet shipped. If the attr()-based CSS route eventually becomes available, authors would gain direct control to handle those elements themselves — and as of Chrome 88, Firefox 89 and Safari 15, the underlying aspect-ratio CSS property is supported, though the ability to source values from HTML attributes through attr() is still missing.

Why Aspect Ratio Is No Longer A Guessing Game

For years, the advice to always include width and height attributes on images felt outdated. With responsive layouts and CSS-driven sizing, many developers dropped them, assuming the browser would handle it. That assumption came at a cost: layout shift. When an image loads and pushes content down, users lose their place, causing the jank that metrics like Cumulative Layout Shift (CLS) are designed to penalize.

The modern fix is elegant. By setting both dimensions in the markup, the browser can calculate the intrinsic aspect ratio before the image even begins downloading. This lets it reserve the correct amount of vertical space in the layout immediately, regardless of how CSS later re-sizes the image visually. The result is that the area occupied by the image is stable from the very first paint, and the page no longer jumps around as assets load.

The Browser’s Built-In Solution

This is where the improvement gets interesting: the browser does all the heavy lifting. You do not need to inject any JavaScript, write a single CSS rule for aspect ratio, or restructure your markup. The only requirement is that the width and height attributes are present. Once they are, the rendering engine takes over.

This automatic behavior removes the developer burden entirely. There is no complex configuration to get wrong, no fallback to test, and no dependency on a third-party script that might fail. If the attributes are there, the browser uses the ratio to allocate space. If they are missing, the old behavior returns and shifts happen again.

Why Responsive Images No Longer Break The Trick

One of the main reasons developers stopped adding dimensions was the rise of srcset and sizes attributes. The logic was that if you are serving multiple versions of the same image at different resolutions, a single fixed height and width could not possibly be right. This was a misunderstanding. The attributes do not have to reflect the final rendered size; they only need to communicate the intrinsic ratio of the source file.

Even with the most complex responsive setup, each candidate image in the set is a specific file. It has its own real, intrinsic width and height. When you specify the dimensions of the default image in your markup, the browser applies that ratio to whatever final size CSS determines. As long as all images in a single responsive set have the same aspect ratio—which they should—the calculation is always correct. The page reserves space accurately even when the user is on a small mobile screen, a large desktop monitor, or anything in between.

A Simple Habit With A Real Payoff

The industry has seen a shift back to this practice because it delivers a tangible user benefit with almost zero effort. For content management systems, blogging platforms, and editorial tools, this is particularly easy: virtually all of them store image dimensions at upload time and can output the attributes automatically.

Data from the HTTPArchive suggests that 62% of <img> tags already include width or height—a higher number than many expected. But that still leaves a significant portion of the web without this basic guard against layout shift. For those remaining cases, the fix is trivial to implement and requires no new dependencies or architectural changes.

The real takeaway is that this is not a regression to old-school fixed-width web design. It is a compatibility layer that enables a modern, performance-driven default. By re-adopting a habit we should probably never have dropped, we get a smoother experience for users at no cost to flexibility.

Further Reading