When you start incorporating the new responsive images standards across your site, the task can seem daunting. How do you know which standards to use and where? How will you maintain the new markup and image sizes?
We have found that a good first step is a responsive images audit.
Much like a content audit, a responsive images audit is designed to help you take stock of the images you have on your site and how they are being utilized.
The output of the audit is often a spreadsheet describing different types of images, the templates they are used on, and what solution you plan on implementing for those images.
Here are some sample questions you should consider asking about the images on your site:
This may seem unrelated to the technical questions of how the responsive images will be implemented, but my experience has been that knowing where the images are coming from, where they are stored, and if anyone needs to modify the image before it is posted can dictate what solutions are practical.
Consider this your reminder that people are still involved and you need to understand the people part first.
We had a client who had badges for awards and types of recognition. These badges were displayed at a small size even when the page was large. We found that even if we had the largest size possible at retina density, the images were about same in file size. So why provide multiple image sizes?
In addition, the images came from third parties and they didn’t have the source which was another good reason to simply use the largest image and have the browser resize it.
Knowing which use case you’re solving for will help determine which syntax makes the most sense.
If the images will work well as vector, then we may be able to use a single image source.
Are there representative images we can use to find sensible jumps in file sizes for our image breakpoints?
Picking responsive image breakpoints remains a tough problem. It can be easier if all the imagery we’re using are things we control and have a distinct style.
If there are representative images, then we can save them at various sizes in the range they will be used in the template and make a determination of how many image sources we need to provide.
In situations where images come from user generated content, it can be harder to find representative images from which you can determine image breakpoints. In that case, we know we’re going to have to make an educated guess about what will work.
Perhaps we’re using a lot of alpha channel images and want to provide JPEG 2000 for those whose browser supports that image format. Or perhaps we want to provide WebP alternatives.
If we determine there is a good reason to do this for a set of images, then that will mean we want to use the <picture> element even if we aren’t doing art direction.
We conducted a responsive images audit for a large site. The end result was a spreadsheet that looked like the table below.
|Property logos||PNG8 (future SVG)||Regular, Retina||<img>||Little variance between the wide and small screen image sizes.|
|Partner logos||PNG8 (future SVG)||Regular, Retina||<img>||Little variance between the wide and small screen image sizes.|
|Brand logos||PNG8 (future SVG)||regular, Retina||<img>||Assumes little variance between the wide and small screen image sizes.|
|Property photography||JPG (conditional WebP)||Dynamically resized and compressed||Non-art-direction <picture>||Templates specify breakpoints.|
|Promo images w/ text (art direction)||—||TBD||<picture>||Content producer defines images and breakpoints in CMS.|
We did this audit a couple of years so we might have different answers today than we did then.
Also, it is worth noting that the property photography represented over ninety percent of the images on the site. We have found this to be common on the sites we’ve worked with.
Once you have your audit complete, you need to combine it with image resizing and processing services so you know how you will implement what your audit recommended. For more on that, check out: