Contemplating the usefulness of responsive images

With smartphones getting bigger and screen resolutions becoming ever more dense, is it still feasible to serve a whole bunch of different image sizes on a photo sharing web site?

I was looking at my own photo journal with my iPhone 13 mini. And I was a little surprised to find that the images with a width of 1280 pixels get served on a screen that small. But it kind of makes sense, and is certainly logical (as I’ll explain).

My main reason to use responsive images – meaning, being able to serve differently sizes images to differently sized screens – is to serve smaller variants to smaller screens. But given the aforementioned phone screen sizes and the way browsers seem to work, is thwarting these plans.

My iPhone 13 mini has a 5.4-inches-sized screen with an actual resolution of 1080 x 2340 pixels. Its 3x scale factor means, it has a logical resolution of 375 x 812 points.

For phone sized screens, my photo journal displays images in almost full screen width (96% or 96vw to be precise). My srcset and sizes declarations use the width-descriptor, letting the browser decide which image to request from a set. Here’s an example for a landscape-oriented image:

<img loading="lazy"
     src="/images/2022/02/960w/001.jpeg"
     width="960" height="640"
     srcset="/images/2022/02/640w/001.jpeg 640w, /images/2022/02/960w/001.jpeg 960w, /images/2022/02/1280w/001.jpeg 1280w, /images/2022/02/001.jpeg 1920w"
     sizes="(min-width: 4370px) 1920px, (min-width: 1613px) 1280px, 96vw">

Given my testing in recent years, browsers always seem to pick the image based on the real pixel width – not logical points. In the case of the iPhone 13 mini, that width is almost (96vw or 96% of) 1080 pixels. And iOS’ Safari (and I believe other browsers as well) will then request the image with the next larger width. Which in my case means that from the (src)set of 640w, 960w, 1280w and 1920w that I provide, the 1280 pixel wide version gets requested. So, for a screen with a logical width of 375 points, an image with 3x the pixel size gets served. And that’s what seems excessive to me.

Looking at it, this somewhat makes sense: the actual pixel width is 1080, so the next larger size would be 1280px. But the thing is: I think the 640px version would look just fine. I’d argue that on a screen this small, most people couldn’t really tell a difference. Granted, if you pinch to zoom in, it would be beneficial to serve the 960px version for some headroom. But 1280px seems to be too much (in my humble opinion).

And my device is even on the smaller side: from what I can gather, most phones are larger and have similar or higher screen resolutions, which might result in even the 1920px size getting served.

I’d argue that smartphones are the smallest devices that make sense to use for looking at photos. But with the previously mentioned ever bigger phone sizes and screen resolutions I feel like it might not make much sense to serve those smaller versions anymore, given browsers only seem to take into account the real pixel-resolution.

My 960px version might currently still make sense for some not-so-current devices. But the 640px one might just be served so rarely, that I could stop generating it.

Instead, I’ll be thinking about approaching responsive images differently. Maybe it makes more sense to generate images using a more modern image format with better compression. For example, I could only generate the larger variants – but in addition to the JPEG variant, also generate an AVIF version. That would yield some file size savings again for devices that support it. In my case, that might mean to only generate the 1280px and 1920px versions, but both as JPEG and AVIF. We’ll see!