When to use img, img@srcset, and picture and source
Post from July 17, 2019 (↻ June 28, 2020), filed under Web Development.
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
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
source) or just
img (easiest overall).
If understandability and maintainability (likewise DX) are the priorities, just use
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.
A Payload and Tooling Perspective
If ultimate payload differences are insignificant, just use
If payload differences are moderate or if no tooling is available, use
If payload differences are large and tooling is available, use
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.
Figure: Pretty much like running into
picture and his friends. (Copyright King Features Syndicate, Inc., distr. Bulls.)
* For another good example of much blind toolism, look at favicons.
† Of course, this also applies to the
oversized-images feature policy.
If you have a question or suggestion about what I write, please leave a comment or a message.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out some of the most important aspects of such CSS. (Also available in a bundle with Upgrade Your HTML and The Web Development Glossary.)
Looking for a way to comment? Comments have been disabled, unfortunately.