8 Guidelines and 1 Rule for Responsive Images

I recently had the opportunity to work with a company that is moving to a responsive design and has over 800,000 images on their site. These images come from all over the world. I learned a lot about what it means to tackle images in a responsive design on a large scale.

One of the big lessons is that we spend a lot of time discussing what the frontend solutions for responsive images should be—the new picture element or srcset or a magical new image format—and little time discussing how backend systems and human processes might need to change.

The company I consulted has procedures in place for images. These processes include having the images enhanced if necessary, cropped to fit, resized, and then saved in a web optimized format to fit exactly how the image is used on the page. That process makes a lot of sense for the current fixed width site, but will break down when the site becomes responsive.

These conversations led me to document my ideal scenario. If I could wave a magic wand for organizations, what would I put in place for their responsive images processes and tools?

The result was eight guidelines and one rule for responsive images.

Wherever possible, avoid the problems of pixel-based images by using vector alternatives.

SVG has decent browser support. The Filament Group has a project called Grunticon that will generate SVG and fallback PNGs along with the CSS necessary for you.

Icon fonts are also a big win with fairly wide support. You can create your own fonts with just the icons you need. A bunch of images can be contained in a single HTTP Request which means icon fonts provide similar performance benefits as CSS sprites used to.

Just make sure you use progressive enhancement for your icon fonts and use them in an accessible manner.

• Can I Use: SVG
• Can I Use: Web Fonts
• Grunticon
• A List Apart: The Era of Symbol Fonts
• IcoMoon
• Pictos
• FontForge

As prices for high-density screens go down, they are starting to show up in more devices and at larger sizes. It isn’t hard to imagine Apple releasing Retina Cinema Displays in the not so distant future.

Having content authors upload the highest quality image they have into whatever system you use to manage content means that you’ll be ready for whatever resolutions are needed in the future. Managing and keeping track of these assets will make life easier if you redesign the site in the future.

Storing the highest quality source files will likely mean an increase in storage requirements, but storage is cheap these days.

If you have a lot of images on your site, it will no longer make sense to resize them and optimize them for the web by hand.

For example, if the client I was consulting with had decided that they needed three responsive image breakpoints, that would mean three times their current 800,000 images. And that is just standard definition. Multiple the number of images by two if you want to support retina displays. The end result would be 4.8 million images.

Now they wouldn’t have to do all the images at one time, but it still a lot of work. So instead, companies need to build or buy centralized systems that will resize and compress images.

That image resizing service? It should be able to take information that identifies a source image as well as the measurements that the image is needed at and resize the image on the fly.

A good example of a service like this is Sencha SRC. See how you can declare in the URL just the width or the height and the service will resize the image proportionately. That’s what you want.

<img
  src="http://src.sencha.io/320/http://sencha.com/files/u.jpg"
  alt="My constrained image"
/>
Code language: HTML, XML (xml)

If you’re an Akamai customer, the Akamai Edge Image Manipulation service might do the trick for you. It is currently in beta and offers a ton of useful functionality.

Whatever you do, you’ll want to make sure you’re providing smart caching and not breaking external caches.

It doesn’t really matter what solution you decide to use in your markup for responsive images. My personal preference is the PictureFill solution, but there are many options to choose from.

But no matter what solution you pick, you should centralize the markup so that it will be easier to change in the future.

For example, in your templates, you might not put any direct HTML, but instead define a series of source images and breakpoints like so:

{
"source":"/source.jpg",
"breakpoints": [
{ "max-width":"30em","pixel-density":1,"width":360px}, 
{ "max-width":"30em","pixel-density":2,"width":720px},
{ "max-width":"30em","pixel-density":1,"width":800px},
{ "max-width":"30em","pixel-density":2,"width":1600px},
{ "pixel-density":1,"width":800px},
{ "pixel-density":2,"width":1600px},
]
}
Code language: HTML, XML (xml)

And then pass that to a central function that would output the correct PictureFill markup or whatever markup you’re going to use.

Don’t get hung up on the syntax or the data contained in the example. The key is that by centralizing image markup in a function, you can change it quickly when the standards evolve.

For most sites, the most important use of responsive images will be to provide different resolutions of images based on the size that the image is used on the page at a particular viewport size. That is what we call the resolution switching use case.

Occasionally you will find that simply resizing an image isn’t sufficient. A smaller version of the same image becomes unrecognizable.

But at a smaller size, the image can be hard to discern.

If you make changes to the image source at smaller sizes, the image can be easier to see.

This is what we call the art direction use case.

Another place where you may need art direction is for images that contain a combination of text and photography. Ideally, you can separate the photography from the text, but sometimes you can’t get the control you need and when you shrink the image, the text becomes unreadable.

For this recent project, we were able to identify a handful of templates where the need for art direction might be necessary. For those templates, the CMS will be modified to allow authors to upload different sources and define at what breakpoints those sources should be used.

If you’re going to centralize your image resizing as a service, this is the perfect opportunity to incorporate the best tools in image compression.

Google has some great information on ways to optimize images. It should also go without saying that you need to set far future expires headers for your images.

As long as you’re centralizing image delivery, why not look into supporting WebP?

The average WebP file size is 25% – 34% smaller compared to JPEG file size. WebP compresses 34% better than libpng, and 26% better than pngout for loseless images.

Google wrote recently about how they’re checking for WebP support when an image is requested and automatically serving up the WebP alternative if the browser is capable of displaying that image.

Ideally, browsers would simply support WebP, but in the meantime, there are some performance gains that could be had and it might not add too much to your image resizing service to support it.

No one knows what the future of responsive images holds. A few years from now, we will probably look back on the hacks we’re using and laugh at our naivety.

The one thing we can be certain about is that we’re going to need to replace what we implement now when standards catch up with responsive images.

So whatever you build, make sure it is flexible and can be changed easily when the ultimate solution for responsive images becomes apparent.