That's a lot of screens, are your images ready? (testing using Adobe Shadow). Photo: Adobe.

No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants their images to look good on the multitude of screens connecting to today’s web. Finding the balance between the myriad factors — screen resolution, screen size, bandwidth, layout and design — is a tricky process.

We’ve looked at a number of techniques for handling images in responsive designs, but one thing that we haven’t covered is where to put the actual breakpoints.

You’re probably familiar with breakpoints in responsive design, they’re the screen widths in your media queries. For responsive images the idea is the same; a “breakpoint” is the screen size at which you swap in and out different size images.

At first glance it might seem logical to use the same breakpoints for your images that you’re using in your CSS media queries, but as Cloud Four’s Jason Grigsby writes, that’s not always the ideal solution. Grigsby tackles the potentially tangled question of breakpoints in a new post, So How do You Pick Responsive Images Breakpoints?

To simplify what can be a very complex question, Grigsby ignores some scenarios, including the so-called “art direction” use case where images are optimized (cropped differently, for example) for different screens. Instead Grigsby focuses on the question of how to best select “different image files with different resolutions of the same image based on the screen size.”

The simplest solution is to just make your image and responsive design breakpoints the same, but that’s rarely going to be ideal for your site’s visitors. Here’s what Grigsby has to say about using the same breakpoints for both image and media queries:

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.

The main problem is, what constitutes an “unnecessarily large file”? But even if you answer that, as Grigsby writes, you still haven’t answered every question:

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.

In the end Grigsby doesn’t yet have an answer to the question of how to handle responsive image breakpoints. And neither do I. There just isn’t an easy answer that will work for every project. My thinking, and what I’ve done on my own site, runs pretty much along the same lines of Eric Portis’s comment on Grigsby’s post. If you’ve got ideas, head over to Cloud Four and let them know how you’re doing it.