When to Use “img,” “img@srcset,” and “picture” and “source”

Published on July 17, 2019 (↻ June 17, 2024), filed under Development (RSS feed for all categories).

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 worked as a technical lead and engineering manager for a few companies, I’m a contributor to several web standards, 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.)