Responsive images has been a relatively hot, recurring topic in the web design and development community since, well, pretty much immediately after responsive design reared its sometimes awesome, sometimes frustrating-to-the-point-of-throwing-a-tablet/phone-accross-the-room head.
I’ve seen many potential ideas for solutions, including, but definitely not limited to:
- Server-size browser/device/screen-size detection and rescaling of images to be delivered. A good example of this is Adaptive Images.
- Loading in ‘mobile’ images by default, sniffing for screen-size and replacing with larger ones (causing double the amount of images to be downloaded on quicker connections).
- The proposal of a new
<picture>element with variable sources.
- Loading different images as backgrounds using media queries for screen sizes (which does work rather well in some cases, actually)
- The list goes on.
And there doesn’t seem to be (I’m sure you’ll correct me if I’m wrong in the comments, or shout at me viciously on Twitter) a decent solution, at the moment.
Just don’t bother
But I have one that works for me precisely 98.21% of the time:
Don’t bother with ‘responsive images’.
Now I’ve lost half the readership, and done ducking under the desk from incoming abuse from the rest, allow me to explain just one of the reasons this actually works perfectly well.
Mobile networks (read: low bandwidth connections) already compress the hell out of served images.
Remember back to the days before responsive web design. Downloading web pages on EDGE/GPRS on the first generation iPhone without 3G? Remember it being really really unbearably slow? Okay, so it was slow, but far from unbearable. Allow me to demonstrate with a picture of Simon Amstell.
Note irony: these demo images probably aren’t going to display well if you’re reading this on a mobile connection, because your carrier will be compressing your images.
Let the mobile networks do the work
Here’s Simon, he’s 1200 x 899, and weighs in at a hugely gratuitous 407KB. Grabbed from Google Images, completely uncompressed. About the size you might use for a homepage carousel on a Simon Amstell fansite, if you were some sort of crazed fan or something. It’s probably a bit bigger than what you might use for that purpose actually, but like I said, grabbed from Google Images, no optimisation, for the purpose of demonstration. Isn’t he lovely?
Now. To emulate a mobile connection, I can tether my generic telephonular device to my generic laptop device, and view it there to see what one would if looking at my Simon Amstell fansite out and about.
Magically, the received image I’ve downloaded using my generic mobile carrier on a 3G connection is still 1200 x 899, but is now only 45KB! Go on, download it and check, you know you want to.
Note from Paul: The sizes quoted vary slightly because of images being screwed with by WordPress. However, the principle still holds true.
Again, mobile networks have already implemented the technologies required so users can make the most of their data allowances, and keep their load as low as possible.
We as developers can simply take advantage of that.
“But why not do that in addition to making sure our images are optimised for ‘mobile’ devices!” I hear you scream!
Well. Amazingly, by being lazy, we actually counteract a negative effect of networks’ (over)compression. Here’s the same image of Simon, resized to a random carousel-ish-sized choice of 360 pixels wide and kept at good quality. It’s now around (a still deliberately gratuitous) 83KB, and looks lovely when viewed over a ‘desktop connection’ at that size. It’d look horrendous if we tried to stretch it to use in a carousel at ‘desktop’ size.
But wait, that same image when viewed on a generic telephonular device… Oh no, that looks horrible with the network’s compression, we’re only downloading 7KB worth of image!
The original, larger, but carrier-compressed image scaled down to mobile fullscreen width, as it would be by being ‘lazy’ and using browser/CSS resizing looks just fine. Lovely and crisp, in fact, even on a screen with 1.5x or 2x the DPI of a standard laptop/desktop, as “most” modern smartphones (regardless of operating system) have. It’s been compressed, so we’d lose some quality at the larger resolution.
But then this is compensated for by the CSS/browser resizing, so it still looks good on a smaller but ‘higher quality’ screen.
And yes, I know, other generic telephonular devices are available, but look at your stats, and then tell me the percentage of users using what would now be considered ‘low-DPI’ displays, compared to other ‘common’ devices, and we’ll have the “can’t we drop IE6 yet” argument.
Coincidentally, this same argument goes for countering the suggestion to provide 1MB images for the 0.000000003% [statistic may be made up] of the world who’ve bought Retina-Screened Generic Laptop Devices, at the moment).
Don’t optimise for specific devices, but do optimise.
Now obviously, being a responsible developer, you stringently check file-sizes of absolutely everything, and optimize images as much as possible anyway, and that’s important, because you still don’t want to be serving any additional bandwidth anywhere, anyway. But optimise the image, not for any guesswork of devices or connections you’re going to be viewing on. That’s a generalisation, of course, and there’ll be situations where you need more specific solutions, but as far as a one-size-fits-all goes, I’ve found it to be a pretty darn acceptable one across all popular devices and connections I’ve come across and tested against. And do, always, consider the use-case, and test. Do carry on doing a good job optimising for your specific audience.
There we go. A crisper image by default, on ‘common’ mobile device resolutions, using one file, roughly an 88% saving of bandwidth where viewed on a mobile connection, and 0% extra effort. You may now resume telling me I should be working ‘hard, not smart’, and I’ll get back to building stuff, and put away my pictures of Simon Amstell.