When to Use āimg,ā āimg@srcset,ā and āpictureā and āsourceā
Published on JulĀ 17, 2019 (updated JunĀ 17, 2024), filed under development, html (feed). (Share this on Mastodon orĀ Bluesky?)
At sum.cumo I almost got the reputation of a srcset
āhater.ā Iāve disliked srcset
and the whole family of ideas around it from the start because doing the same thing (embed an image) for the same purpose (show an image of a particular meaning) several times (create images of the same meaning in different sizes, cuts, or formats) has usually looked like too much DX cost for too little UX gain to me. The goals of srcset
and the problems it tried to solve were clear, but that didnāt improve any of this bad taste.
Before I go on, here are examples for the three ways of embedding images that weāre going to discuss, simplifying MDN:
<!-- `img` element -->
<img src=foo alt=bar>
<!-- `img` element, `srcset` attribute -->
<img srcset="foo-320w.jpg 320w, foo-480w.jpg 480w, foo-800w.jpg 800w" sizes="(max-width: 320px) 280px, (max-width: 480px) 440px, 800px" src="foo-800w.jpg" alt=bar>
<!-- `picture` and `source` elements, `srcset` attributes -->
<picture>
<source media="(max-width: 799px)" srcset=foo-480w.jpg>
<source media="(min-width: 800px)" srcset=foo-800w.jpg>
<img src=foo-800w.jpg alt=bar>
</picture>
Tooling, now, the card that developers habitually play, and that some of my colleagues have played, too, is not an always playable card to meāif you think about it, just because someone could produce garbage automatically wouldnāt make that an argument to produce garbage, and therefore it still behooves us to think about what weāre using tooling forĀ *. Apart from that, I generally believe itās useful to keep things simple yet also a tad difficult. You can tell how ātooling,ā from this view, cannot be a satisfactory answer to the question whether and how to provide additional image sizes and formats.
Yet, is providing different image sizes, cuts, and formats indeed such a terrible thing? There doesnāt seem to be a single general answer. Hereās the perimeter as I see it, coming from two angles.
A Priority Perspective
If performance (UX) is the priority, then use img@srcset
or picture
and source
, whichever yields better results or uses less code, as long as image weight savings are bigger than the HTML payload increase (compared to just img
). For an example where one should probably pass on a size, see the flamingo example on HTML.com (and skip output like flamingo3x.jpg).
If simplicity (DX) is the priority, use img@srcset
(easier than picture
and source
) or just img
(easiest overall).
If understandability and maintainability (likewise DX) are the priorities, just use img
.
Weāre working with some conditions here and I do grant DX that it can be a legitimate priority if UX is only mildly impaired. The simple rationale behind this is that a terrible DX will ultimately result in a terrible UX, so DX cannot be ignored. UX and DX donāt correlate, and so both may be priorities.
A Payload and Tooling Perspective
If ultimate payload differences are insignificant, just use img
.
If payload differences are moderate or if no tooling is available, use img@srcet
.
If payload differences are large and tooling is available, use picture
and source
along with alternative image formats (like WebP) to achieve maximum performance.
ā§ The point is, now, that it all dependsĀ ā , that we still need to think, and that web development is still about probabilities. And, sure, that skepticism has nothing to do with āhating.ā But everyone knows that.
Update (May 3, 2021)
The HTML specification, by the way, has a pretty nice section on embedding images and what to consider for it. It doesnāt match the advice Iāve been giving here, butāitās the spec and this part of it is pretty detailed.
* For another good example of much blind toolism, look at favicons.
ā Of course, this also applies to the oversized-images
feature policy.
About Me
Iām Jens (long: Jens Oliver Meiert), and Iām a web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), and I write and review books for OāReilly and Frontend Dogma.
I love trying things, not only in web development and engineering management, but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (I value you being critical, interpreting charitably, and giving feedback.)