❮ HTML
Try it Yourself »
The width
attribute specifies the
width of an image, in pixels.
Tip: Always specify both the height
and
width
attributes for images. If height and width are set, the space required for the image is reserved when the page is loaded. However, without these attributes, the browser does not know the size of the image, and cannot reserve the appropriate space to it. The effect will be that the page layout will change during loading [while the images load].
Tip: Downsizing a large image with the
height
and width
attributes forces a user to download the large image [even if it looks small on the page]. To avoid this, rescale the image with a program before using it on a page.
Browser Support
width | Yes | Yes | Yes | Yes | Yes |
Syntax
Attribute Values
pixels | The width in pixels [e.g. width="100"] |
❮ HTML
The width and height attributes of the IMG element specifies the width and height of an image.Browser Type
width=" " | pixels or % | the size of the width |
height=" " | pixels or % | the size of the height |
Example
Sample image
[width:193px, height:130px]
[width:193px, height:130px]
[width:96px, height:65px]
[width:100%, height:130px]
Output- 18 min read
- Browsers, Performance, Optimization, Core Web Vitals
width
and height
attributes on your images to prevent layout shifts and improve the experience of your site visitors.Web performance advocates have often advised to add dimensions to your images for best performance to allow the page to be laid out with the appropriate space for the image, before the image itself has been downloaded. This avoids a layout shift as the image is downloaded — something Chrome has recently started measuring in the new Cumulative Layout Shift metric.
Well, a dirty, little, secret — not that well-known outside the hard-core web performance advocates — is that, until recently, this actually didn’t make a difference in a lot of cases, as we’ll see below. However, adding Lorem ipsum dolor sit amet, consectetur adipiscing elit…width
and height
attributes to your
This might render in two stages, first as the HTML is downloaded, and then second once the image is downloaded. With the above code, this would cause the main content to jump down after the image is downloaded and the space needed to display it can be calculated:
Layout shifts are very disrupting to the user, especially if you have already started reading the article and suddenly you are thrown off by a jolt of movement, and you have to find your place again. This also puts extra work on the browser to recalculate the page layout as each image arrives across the internet. On a complex page with a lot of images this can place a considerable load on the device at a time when it’s probably got a lot of better things to deal with!
The traditional way to avoid this was to provide Lorem ipsum dolor sit amet, consectetur…width
and height
attributes in the
Then the render happens like below, where the appropriate amount of space is set aside for the image when it arrives, and there is no jarring shift of the text as the image is downloaded:
Even ignoring the annoying impact to the user in content jumping around [which you shouldn’t!], the impact on the CPU can also be quite substantial. The below screenshot shows the performance calculations performed by Chrome on a site I work on
which has a gallery of about 100 images. The left-hand side shows the calculations when width
and height
are provided, and on the right when they are not.
As you can see, the impact is considerable — especially on lower-end devices and slow network speed, where images are coming in separately. This increases load time by a noticeable amount.
How CSS Interacts With Element Widths And Heights
Widths and heights on an image can cause issues when you try to alter them using CSS. For example, if you want to limit your images to a certain width you might use the following CSS:
img {
max-width: 100%;
}
This will override the width
of the image and constrain it when necessary, but if you have explicitly set the height
on the image tag, then we are not overriding that [only the width] and you will end up with a stretched or squashed image, as we
have no longer maintained the aspect ratio of the image:
This is actually very easily fixed by adding a height: auto
line to the CSS so the height attribute from the HTML is overridden too:
img {
max-width: 100%;
height: auto;
}
However, I find it still catches people by surprise and sometimes leads to them not specifying image
dimensions in the HTML instead. With no image dimensions, you can get away with just specifying max-width: 200px
in the CSS without having to specify height: auto
and the browser will automatically figure out the height itself — once it has the image.
So, once we add the dimensions and that the height: auto
trick, we get the best of both worlds, right? No layout shifts, but also the ability to resize images using CSS? Well until very recently you might have been surprised to find out the answer
was in fact: no [I was — hence why I decided to write this article].
For example, take the code below:
img {
max-width: 100%;
height: auto;
}
Your title
Introductory paragraph.
Lorem ipsum dolor sit amet, consectetur…
This would have resulted in this load:
height: auto
is used in CSS.
[Large preview]Wait, what’s going on here? We’re back to the first problem. I thought I said that by specifying the image dimensions in the HTML you could avoid this layout shift problem? Well, this is where it gets interesting and will lead on to the main point of this article.
The problem is that, unless you were giving explicit width
and height
CSS values to your images — and who wants to limit themselves like that in a responsive world where you want the image to expand or shrink to fill up the available space — then CSS will need the dimensions from the image file itself to figure out the auto
part of the dimensions. It ignored any width
and height
attributes set in the HTML.
The implication of all this is that specifying width
and
height
attributes on images often wasn’t actually that useful in a lot of cases. Yes, when an image is being shown at full size, without any CSS changing any dimensions, it is useful to resolve the layout shifting problem. However, when you use CSS like below to ensure images do not overflow their available space, then you run into problems as soon as the available width becomes smaller than the actual image size.
img {
max-width: 100%;
height: auto;
}
This affects any page where we constrain the image size in a responsive manner — i.e. small screen mobile devices. These are likely to be the very users suffering with network constraints and limited processing power that will suffer most from layout shifts! Of course, we ideally should be delivering appropriately sized images for the screen size, but you cannot cover every device size, so often images will need some resizing by the browser, particularly on mobile.
Many websites may not bother to specify width
s and height
s on their
Rather than hard-coding the aspect-ratio
, this uses the attr
CSS function to create the appropriate aspect-ratio based on the image width
and height
attributes provided by the HTML. The attr
function has been around for a while, but has been very limited in scope — it’s
supported for content
by all browsers, but not for the wider use case of any other attribute like width
and height
, which is what is needed here.
If attr
was able to be used for the
well-known width
and height
attributes from img
elements, then it could use be used to automatically calculate the aspect-ratio
as per above. This would solve issue 1 [no hard-coded aspect ratio needs to be set in the HTML nor the CSS], issue 2 [very simple to add] and, as we shall see, there is a very simple answer to issue 3 [adoption].
Basically, this solution means if the following four conditions are true, then the correct image dimensions could be calculated without needing to wait for the images to download, and so without the need of a content layout shift:
height
is set on the element in HTMLwidth
is set on the element in HTMLheight
[orwidth
] is set in the CSS — including using percentage values likemax-width: 100%;
width
[orheight
] is set toauto
in the CSS.
If any one of these were not set, then the calculation would not be possible, and so would fail and be ignored and have to wait for the image to be downloaded.
So once browsers support using the HTML width
and height
to calculate the aspect-ratio
we can solve our problem very simply with no change in practice to HTML and one line of CSS code! As mentioned above, this is also something many web developers may have already assumed was happening anyway.
Driving Adoption Of This Solution
Because this is just a CSS attribute, the proposal contained a further twist — it could be added to the user-agent stylesheet used by browsers so would not even require any changes from web developers to benefit from this.
The user-agent stylesheet is where default CSS definitions are set [e.g. what font-size
the h2
element uses], which can be overridden by your own CSS if you want. By adding the above aspect-ratio
one-liner to this we don’t need to drive adoption — we basically turn it on automatically for all sites that meet the above four conditions!
However,
this does depend on the attr
function having access to the width
and height
HTML attributes, and also the upcoming aspect-ratio
CSS property to be completed — neither of which has happened yet. So instead, as an easier fix, the browsers could implement the equivalent logic deep in rendering code rather than exposing it via the user-agent stylesheet, but the effect is the same. This alternative implementation approach was even
suggested as part of the proposal.
Firefox went ahead and did this as an experiment and then turned it on by default for Firefox 71. Once that was released, then your site may well have just got faster for free — thanks Mozilla! Maybe in future, they will move this to the user-agent stylesheet method, but for now, this is sufficient [and perhaps more performant?].
Backwards Compatibility
When introducing a change in behavior, there is always a concern about backwards compatibility and this feature was no different. In theory, as long as the four attributes were appropriately set, there should be no breakage with this.
However, when Firefox initially
experimented with it, they discovered problems for those setting the width
and height
incorrectly in their HTML. Whereas previously these incorrect values would be ignored if the CSS overrode them, now they were being used when auto
was set and the images were not displayed correctly and led to squished or stretched images. Now you could argue that web developers shouldn’t set these values incorrectly, and in some cases, it would be already broken even without this change [the case
above when you didn’t set height: auto
], but still, breaking sites is never a good thing. That is also something the web tries very hard to avoid — and is mostly very good at avoiding that [it’s one of my favorite things about the web as a platform].
The solution to that problem, however, was relatively simple: have the actual image aspect-ratio of the image override any CSS calculated aspect-ratio. This way the [incorrectly] calculated aspect-ratio can be used for initial layout, but then can be recalculated when the image is downloaded, so the image is displayed as it was before. This does cause a layout shift [since the incorrect space was allocated initially] but that was happening before anyway, so it’s no worse. In fact, it’s often a lot better as an incorrect aspect ratio will often be closer to the truth than a zero aspect-ratio.
Rollout To Other Browsers
After Firefox’s successful experimentation, Chrome also decided to implement this [again using the layout coded method for now rather than default user-agent stylesheet], and rolled it out by default in Chrome 79. This also took care of the other chromium-based browsers [Edge, Opera and Brave, for example]. More recently, in January 2020, Apple added it to their Tech Preview edition of Safari, meaning it should hopefully be coming to the production version of Safari soon, and with that, the last of the major browsers will have implemented this and the web will become better and less jolty for a huge number of sites.
Limitations
There are a few limitations to be aware of with this feature, including issues with:
- Art Direction
- Lazy Loading
- Non-Images
Art Direction
The fix works great to calculate the aspect-ratio based on a fixed width
and height
, but what about when those change? This is known as art direction and an example is shown below:
In this case we are using a wide image for desktop, and then a square, cropped image for mobile. Responsive images can be implemented with the picture
element like this:
Currently, this only allows the width
and height
to be set once on the main, fallback
Perfect! Well, unfortunately, I discovered this height and width solution is not compatible with the recently released native lazy-loading functionality as can be seen on this test page. I’ve raised a bug for this issue and hopefully the Chrome team will fix this soon. [Update: This was fixed in Chrome 83.]
Non-Images
Currently, the browsers that have implemented this, have only done for the