One of the first web design problem I was asked to solve had a lot to do with images. My client was a photographer with a slow loading site. Naturally the site was image heavy given the subject matter, but the person who had developed it compounded the problem by creating images where none were necessary.
Just about everything that could be turned into an image was an image. Page headings were images, every menu item was its own unique image, borders between photographs were added directly to images, even large swatches of solid background colors were images.
A large part of my job was to remove images where possible and to optimize images that had to remain. Before I worked on the site, pages took 2 1/2 to 3 minutes to load. When I was done they were loading in under 10 seconds.
Responsive design comes down to being flexible over a certain range of conditions and then making more significant changes at the end points of these ranges
Images add a lot to any website. They also create bottlenecks in performance. While bandwidth has significantly increased over the years, images still present performance and other challenges for responsive designers.
Over the next few weeks I want to talk about images in the context of responsive design. There’s a lot to cover so I’ll break the discussion into several posts.
Today I’ll discuss the issues. Next week I’ll provide a long list of resources to solutions that currently exist. After the holidays I’ll pick up the topic again and offer some thoughts for where I think we need to look for long term solutions.
The Issues with Responsive Images
When you consider the different issues we face working with images in a responsive world I think you can group them into a small handful of categories
- aspect ratio and hierarchy
- art direction
If you think about responsive design in general, much of it comes down to being flexible over a certain range of conditions and then making more significant changes at the end points of these ranges. It’s easy to see in responsive layouts and it also occurs with images.
The first item above clearly falls into the flexibility part of responsive design and it’s an issue that’s pretty much solved. The rest come down to changing things at the end points of ranges, which is a more difficult problem and one we may not yet have the tools to deal with.
Let’s look at each in a bit more detail.
Like I said, the issue of making images flexible is pretty much solved. You set the following css on the img selector and you’re set.
That doesn’t mean we’re done. Remember responsive design is about flexibility over a certain range. Flexibility is the easy part. The harder part is how we transition between ranges.
The flexible solution ensures that images will always shrink to stay within their container. However, they won’t grow beyond their maximum size and even if they could their quality would degrade. This means when creating responsive images, we often create them at the largest size possible for the widest of screens.
Larger dimension images mean larger file sizes as well. That’s fine for those big widescreen browsers likely connected to a high speed network, but it’s not so good for devices connected over a slower network that have to wait and wait and wait for our heavy images to load.
Those low bandwidth connected devices would prefer a smaller image in terms of file size, especially as they’re more likely to be smaller devices. I say likely because we can’t really make assumptions that smaller screens mean lower bandwidth. In some cases, the opposite is even true.
Ideally we want to be able to load the most appropriate image in terms of page weight to different devices and different conditions. The issue gets compounded by retina and other pixel dense images. We have some devices capable of displaying the extra pixels and some not capable and again we want to load the appropriate image for each.
Neither of the above performance issues are specific to responsive design. Responsive or not, we’d still have to choose which images to display. However, if building device specific sites we can make that choice and only include the appropriate image. In the case of responsive design we need to include all of the possible images because we don’t know device and context in advance.
While solutions are available to display the appropriate image, the other images are often downloaded to the device, which is kind of what we were trying to avoid in the first place.
Aspect Ratio and Hierarchy
Because our solution to the issue of flexibility is to limit the image dimensions in one direction it causes an interesting issue in maintaining hierarchy between horizontal and vertical images.
Using max-width to limit image dimensions means that horizontal images scale more than vertical ones. As the screen gets smaller horizontal images get smaller more quickly than vertical images, where width is the smaller dimension.
A horizontal image that is larger and thus higher in importance in the hierarchy on wide screens can become smaller and thus lower in importance in the hierarchy on narrow screens. Sometimes this may not be an issue, but more of the time it is and we’d prefer to maintain the hierarchy.
Solutions do exist for this aspect ratio and hierarchy issue and they generally involve hiding parts of the images in order to maintain hierarchy while also maintaining aspect ratio.
This issue isn’t really what it means to art direct, but it’s the name that seems to have stuck so I’ll use it here as well. The issue is that the details of an image seen clearly when the image is large disappear when the image is small.
Depending on the specific image this may not be an issue, but as you might guess, more often it is. Any image should be chosen for what it communicates and how what it communicates relate to everything else in the design. Losing image details can change what’s communicated and many times it would be better to crop an image to present either a specific detail from the large image or even a completely different image to smaller screens.
Solutions to this problem will be similar to those used to solve the performance issues described above. The goal is to be able to serve different images to different devices and ideally only have the image we want to display be the one that downloads to the device.
Throughout this post when talking about images, I’ve been referring to those we embed in html. CSS background images have the same issues, but require different solutions and different considerations.
In some respects the issues aren’t as critical, since background images should more often than not be less important. That’s why they’re in the background and not the foreground after all.
Sometimes though, they’re placed in the background of an element that’s in the foreground. Adding them as a background image is more for technique than because the image isn’t important.
CSS background images are usually easier to target. It’s easier to change the source or to hide portions of the image, however we still face the issue of serving more images than necessary or serving too weighty an image where we don’t want.
The point of this section is to highlight that image issues aren’t only about those we embed directly in html, but also include background images we add through css. The issues are still the same. What’s different are the solutions.
A responsive site is flexible over a series of ranges. Across the end points of these ranges more significant changes are made. In theory a responsive site might only have one range and no need to transition across end points. In practice there are usually several ranges and multiple end points.
The flexible part of responsive design is actually quite easy. What’s more difficult is how we transition over the end points. The issues we face with responsive images are mainly about the changes across breakpoints.
The most significant of the issues revolve around performance. How do we deliver only the most appropriate image without requiring all images be downloaded? Is it ok to deliver multiple images as long we don’t leave visitors waiting for content? Are there solutions where the image itself adapts so only a single image is needed.
The issues of maintaining hierarchy and wanting to art direct the communication, probably aren’t as critical as those of performance, but they’re important issues to solve nonetheless.
Next week I’ll offer a long list of resources to many of the solutions being used to deal with the issues mentioned here. I’ll follow that post in the new year with some general thoughts about where I think we should be looking for solutions in the future.
Download a free sample from my book, Design Fundamentals.