Looking Forward to (Hopefully) Not Needing Responsive Images One Day

I’ve decided I don’t like the responsive image API in HTML, or at least the idea that we still need it as a performance tool.

By "responsive," I mean "show different versions of an image based on device," using only HTML. If it’s been a minute, here’s a recap. You can render responsive images in two flavors: the <img> element with a srcset attribute, or the <picture> element.

Let’s say we’re working with a larger JPEG – 2,000px wide. Using an image tag, you might create two versions and render them based on viewport size:

<img 
    src="ur-mom-2000px.jpg" 
    srcset="ur-mom-600px.jpg 600w, ur-mom-2000px.jpg 2000w" 
    sizes="(max-width: 600px) 100vw, 2000px" 
    alt="Your Mother"
>

Or using a picture element, it’d look like this:

<picture>
    <source media="(max-width: 600px)" srcset="ur-mom-600px.jpg">
    <source srcset="ur-mom-2000px.jpg">
    <img src="ur-mom-2000px.jpg" alt="Your Mother">
</picture>

The outcome is good for users. Mobile devices won’t download the larger image, saving on page load time and data transfer.

But using either of these approaches pretty lackluster:

• They're confusing. You might've had a different experience, but I have to re-read the documentation on responsive images every time I'm about to make one. You're dealing with various attributes, media queries, multiple image paths, and descriptors you'll never use anywhere else. Nothing about it is intuitive.
• It requires too much prep. Before you write any code, you need to determine the breakpoints you'll support, and then work out a process for generating multiple sizes of the same image (my example shows two versions, but you could go beyond that if you'd really like to optimize for different screen sizes). There are platforms and tools that abstract a lot of that work away from you, but relying on another party just to leverage an API is a possible signal that the API sucks to begin with.
• There are collateral costs. Resizing images will cost someone's time, even if it's setting up an automated process, and it's not free to host all those extra images somewhere. The cost probably won't be debilitating, but it's more than zero. And I'd rather be spending that money on something important, like Costco kimchi.

A Lighter Future

Fortunately, responsive images will continue to see diminishing returns as times goes on. Modern formats like WebP and AVIF are exploding in adoption, making the weight difference between mobile & desktop images less drastic.

Take that 2,000px from earlier. At it's original size, it weighs about ~144kb. But after converting it to AVIF at a quality level virtually indistinguishable from the original, you can get it down to about ~20kb without changing its dimensions.

With this kind of savings, taking on the work of resizing images, storing them, and writing weird markup just isn't worthwhile. Stick with that single image and you're golden.

In fairness: performance isn't the only value proposition offered by responsive images. They're useful for artistic reasons too (maybe you want a completely different image to appear only on mobile devices). Plus, the <picture> is handy for falling back to older formats if a browser doesn't support a modern one.

But outside of those use cases, I'd love to not have to reach for these tools more often. And thankfully, it seems to be there's a good chance I'll be getting my way. Especially if every one of you tries out PicPerf.