How do you pick responsive images breakpoints?
For a few months now, I’ve been puzzling over the question of how to pick responsive images breakpoints. It has become a koan to me—no more answerable than the sound of one hand clapping. And as long as I’m haunted by the question, I thought I would share the joy.
What responsive images am I talking about
First, let’s make sure we’re talking about the same thing. In this case, when I refer to responsive images, I’m not talking about:
- An image that is edited depending on the size of the screen. (what I previously called the art direction use case.1)
- Different images for different display densities.
What I am talking about is:
- Selecting different image files with different resolutions of the same image based on the screen size.
- A desire to provide these different image files so that a browser doesn’t download an unnecessarily large file.
Basically, the classic use case that got us all looking at responsive images in the first place.
Defining image breakpoints
In responsive designs, we refer to breakpoints as the screen widths at which media queries are used to make changes to the layout. These breakpoints should be determined by the content, not by common device dimensions.
(For more on setting responsive design breakpoints, I highly recommend this excerpt from Tim Kadlec’s new book Implementing Responsive Design)
Image breakpoints are similar. What are the screen widths at which you switch from one image file to another?
Shouldn’t image and responsive design breakpoints be the same?
Not necessarily. If we were talking about the art direction use case, then it is likely that the breakpoints would be the same because changes in the layout might also indicate an edit to the image.
But in the case where we’re simply changing files to provide different resolutions and a faster download, the image breakpoints should be determined based on when the browser is downloading an unnecessarily large file.
Scott Jehl recently made this point on the WhatWG list:
In the responsive layouts I’ve worked on, content image sizes and their breakpoints were chosen for completely different reasons than the design (CSS) breakpoints: the former for sensible jumps in file size to match screen dimension and/or density, and the latter for how content modules are visibly designed at given viewport dimensions.
Design breakpoints can be plentiful, especially when factoring in all the minor and major tweaks in multi-column responsive layout. Yet for content images, I’ve found the need for fewer breakpoints, or even entirely different breakpoints than the design. In a site like the bostonglobe.com for example, 2-3 image sizes provide sensible jumps in file size, and because the images live a fluid layout, they scale to fill the layout gaps as the CSS breakpoints shift much more frequently around them.
So unless the image is changing in coordination with layout changes, the breakpoints for images do not need to coincide with the breakpoints for layout. In fact, coordinating them may be less ideal.
So how do we pick “sensible jumps in file size”?
This is the question that has been troubling me. If we’re going to tell people creating responsive designs that they shouldn’t tie their image breakpoints to their designs, what guidance can we give them on how many file sizes make sense and when should they switch to a different file size?
To wit, how do you determine what is an unnecessarily large file? Is that 1 byte? 10k? 20k?
And if you can answer that question, how do you determine the resolutions at which those file size jumps are going to occur? Depending on the content of an image and the compression algorithm used, images are likely to have different resolutions at which they experience significant changes in file size.
On a large site with a mixture of gif, png, and jpg images, can you pick common image breakpoints? If so, how?
As I wrote a few months ago:
The problem is there is nothing intrinsic to the image that would guide you in deciding where you should switch from one size of the image to another. Whatever we select will be entirely arbitrary unless we base it on our design breakpoints.
And basing our image breakpoints on our design breakpoints is not ideal.
The correctly sized image
The only thing we can absolutely say about what size image should be used for a given screen size is that the ideal solution is one where the resolution of the image matches precisely the size that the image is in the page.
Of course, this isn’t practical unless we have find the holy grail of responsive images—a magical new image format where a single file provides all resolutions and the browser only has to download what it needs to fill the space on the page. And even if we find the format, we’d have to hope it wasn’t legally encumbered and that all of the browser makers could agree on it.2
In the meantime, I’m stuck pondering the question of what to tell people when they ask how many image sizes and what breakpoints should they use in their responsive designs.
If you have ideas, I’m all ears. But please explain how you come to that conclusion and how you would advise another designer, on a different project, to figure out what image breakpoints would make sense for them.
- Stephen Hay and I have been discussing how art direction may be misused as a label for this use case. We’ve been discussing different names for it, but haven’t settled on anything yet.
- The easiest thing to do in discussions about issues like this is to insist that we need a new image format. I understand the sentiment and if I had a magic wand, I’d make it happen. But until someone—and by someone I mean a large company with intellectual property and lawyers to back it up—steps forward to volunteer a new image format for consideration, we’re stuck with the cards we’ve been dealt. That means that sooner or later, we’re all going to be trying to figure out how to decide where to set image breakpoints.
Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.