Here’s an photo of a cute puppy. Let’s call him Jumpy:
(Photo credit: Szlivka Róbert on Flickr)
Jumpy loves being the center of attention and wants to be seen by the whole wide web. But in order to do so, we’ll have to make sure we serve the best possible version of his photo to everybody.
Meet Alice. She browses the web on her good old MacBook, so we serve her a big, nice image called Jumpy-800.jpg. Alice is happy because she saw a cute dog. Jumpy is happy because he’s a dog, and dogs are mostly always happy.
Now Bob also browses the web on a MacBook, but his eyes are not as good as they used to be, so he likes to zoom in a couple times on his websites. On top of being a good dog, Jumpy is also a great web designer so he knows that when people zoom in, your site should act as if they had a smaller screen.
Quick, which image do you show to Bob?
Well, since he zoomed in, the image now takes up more space, so you want to show him Jumpy-1200.jpg. That’s, right even though Bob is viewing your mobile site, the ideal image to show him is actually larger.
But let’s ignore Bob for a moment. After all, who cares about old people? Everybody knows that the next generation is all about mobile.
So let’s meet Charlotte, 16, dog lover and iPhone addict. She’s only 16 so she can’t afford the new iPhone7 with the built-in holo-camera and taser. Instead, she’s still using her mom’s old iPhone 3GS (Her friends make fun of her at school because of it. Life is tough for a teenager).
When Charlotte goes to Jumpy’s site, we serve her Jumpy-300.jpg because it’s lightweight and will fit nicely in the 320px-wide screen.
Dennis is Charlotte’s classmate, and he happens to be a rich, spoiled brat who always has to have the latest technology. Of course, he’s sporting a brand new iPhone7 with retina screen.
The retina screen has twice the pixels of a normal screen, so we show him Jumpy-800.jpg (800 is close enough to 600, no need to create another image)… except that sometimes he’s on 3G and downloading a big image would take forever, so in those cases we still show him Jumpy-300.jpg.
So what have we learned today? First of all, that responsive images are a mess.
Second, that there are actually four independent factors that affect a site’s layout and its images:
- Screen width
- Screen resolution (i.e. retina or not)
You don’t have to take all of them into account all of the time, but you should at least be conscious of them. It’s especially easy to forget about bandwidth and zoom.
The other takeaway here is that not all these factors are equal. Looking at a stretched out image is not a huge deal for most users, but waiting 30 seconds for the image to load is. So clearly bandwidth is (or should be) the most important factor.
It Gets Messier
Actually we can throw in another bonus factor in there: art direction. Maybe instead of showing the same image at different sizes, you’ll want to crop it or modify it somehow based on the rest of the layout.
But if you have a special cropped version of your image for small screens, then you could conceivably argue that you also need a high-resolution version of the same cropped image for mobile retina screens.
Thankfully, this is still an edge case and we can reasonably assume for now that you’ll be showing the same image to everybody, just at different sizes.
And one more thing…
Not so fast! I’ve got another often-ignored factor: the actual contents of your image.
For example, retina versions may make sense for photos, but what about screenshots? If your screenshot is smaller than 300px and you’re showing it at a 1:1 scale, you won’t be able to conjure up the extra pixels out of thin air.
Also, if your image is a logo or pictogram, it might make more sense to simply use a .svg or even a font and ignore this whole mess.
Now that you’ve got a better understanding of all the factors involved in serving responsive images, you’re probably wondering which solution you should choose.
So my goal with this article was not so much to duplicate his work, but more to give you a couple real-life examples and consider the perspective of the user (and not just the developer, like many articles on this topic out there).
But I’m currently trying out a couple options myself, and I’ll be sure to write a new post or update this article once I’ve settled on a solution. In the meantime, let me know in the comments which solutions you like best!