Responsive Web Design, Part 2 (2015)
Responsive Images
The Importance Of Image Optimization
The savings that can be achieved by responsive images don’t reach their full potential unless you properly optimize your images. Image optimization techniques have been available for a long while now, yet many web developers don’t apply them and let their users download excessive image data. What can we do to change that?
Covering the whole subject of image optimization is beyond the scope of this chapter, but I feel I should cover the basics. Consider this Image Optimization 101.
IMAGE FORMATS
The web has traditionally had three universally supported raster image formats: JPEG, PNG and GIF. In modern browsers, it also has a vector-based format: SVG.
GIF is the most limited format, and aside from being the universal way of showing short animations of cats, there’s not much else it is particularly good at, so we won’t expand any further on it here.
JPEG is over 20 years old and is pretty good at handling photography. It is what is called a lossy image format, which means that when an image is compressed into a JPEG, some quality is lost along the way. That is due to its nature, which mimics the way humans perceive imagery – it gets rid of data that represents changes in the image that are barely visible to the human eye. The format doesn’t do as well for computer-generated graphics with very sharp edges, since the lossiness of the format can cause visible artifacts. Another feature lacking is support for transparency, not to mention a full-fledged alpha channel.
PNG has also been around for a while (since 1996). Unlike JPEG, it is best used for images that have sharp color differences, such as computer-generated graphics. Also unlike JPEG, it is a lossless format, meaning that encoding a PNG does not reduce the image’s original quality. It is an improved and patent-free version of GIF, and has multiple modes that enable it to display photography with true colors (usually referred to as PNG24, as opposed to PNG8 which can only have up to 256 colors). However, since it is not well-adapted to that, these files often tend to be significantly more bloated than their JPEG counterparts. On the other hand, it has a full alpha channel, which means that you can have transparent or semi-transparent parts in your images.
SVG is extensively covered in Sara Soueidan’s chapter, but in short it’s a markup-based format that represents images as mathematical vectors, enabling them to keep their original sharpness when scaled up or down. Sounds like the perfect solution for the responsive images problem! Unfortunately, like PNG, it is best suited to computer-generated images, and when the images in question have many small details, or are not extremely large, it is possible that the SVG version would be larger than the PNG counterpart.
The main takeaway here is that you should pick the best format for the image you want to display. If it’s a photo, chances are that the best format is JPEG. If it’s a computer-generated image with sharp edges, it’s likely that SVG or PNG are best. And if you need your photo to have a transparent or semi-transparent alpha channel, your choice is between using a PNG or using a glorious hack25 combining a JPEG and a PNG alpha mask inside an SVG!
MOAR IMAGE FORMATS!
While the formats described above are supported by all modern browsers, we’ve already discussed other image formats on the web that are only supported by a subset of browsers; specifically the WebP and JPEG-XR image formats, promoted by Google and Microsoft respectively.
JPEG-XR is mainly a JPEG replacement with some additional features (such as an alpha channel) and improved compression algorithms. It is designed to efficiently represent high definition photography.
WebP, on the other hand, is trying to answer the use cases of all other raster image formats. It has a lossy mode designed for photography (that sports an alpha channel as well), a lossless mode designed for computer-generated images, and an animated mode, designed to tackle animated GIFs. The format is based on the VP8 video format.
Both these formats provide compression benefits over the older image formats: both cite around 30% compression improvements over JPEG in various benchmarks. As we discussed, JPEG-XR is only supported by IE, and WebP only supported by browsers that are built on Chromium, so Chrome and Opera.
IMAGE OPTIMIZATION
Once you’ve determined the best format for the image in question, you still need to convert it to the appropriate format, resize it and optimize it. Let’s take a look at how that’s done.
RESIZING
Manual image resizing can often be done by using the built-in resizing utilities in your favorite image editor. Some of these utilities even provide a GUI for performing batch conversions, so avoiding some of the manual hassle. There are also command-line utilities (e.g. ImageMagick) that enable you to handle image resizing tasks. They are often more adapted for batch conversions, using scripts.
Which image dimensions should you pick? Ideally, the various resources that you provide in srcset should not be that far apart when it comes to byte size. In this way, the browser can pick a resource whose dimensions are as close to ideal as possible.
What do I mean by “not that far apart”? Well, that depends on your performance budget26, your server storage space, server CPU costs, and so on. The best way to go would be to test your site over typically used viewports (which you can probably get from your analytics data), and see if the amount of wasted image data fits within your performance budget. If it doesn’t, then decreasing the steps between the image resources inside your srcset and adding some intermediate sizes may help. These intermediate resources would enable browsers to download images closer in size to their actual display dimensions.
Testing how far off are you from ideal image dimensions can be done using a command-line utility I wrote called Sizer-Soze27, which the good folks at the RICG later turned into a web service at sizersoze.org28. You can use it to test the wasted image bytes on your website for popular layout breakpoints, and figure out how far you are from ideal image dimensions. The main downside with the utility is that you must include a polyfill in your pages to see the benefits of srcset and <picture>, since the utility is based on PhantomJS, which itself is based on an old WebKit engine lacking support for these features.
OPTIMIZATION
Image optimization techniques are divided into two kinds:
•Lossless optimization: an optimization technique that doesn’t result in any quality loss as far as the image goes. This can be comprised of elimination of irrelevant metadata, as well as lossless recompression of the image data, crunching the data some more. This type of compression is, as it were, free (i.e. the image quality is unharmed, the only cost for it being server CPU) but is often limited.
•Lossy optimization: an optimization technique that results in some quality loss: either the loss of some precision, the introduction of subtle artifacts, or the loss of some colors.
Despite its name, lossy compression often goes unnoticed by users. But it does come with a quality price and the lossier the compression engine settings are, the worse image quality will be.
The best tool for lossless image optimization out there is Kornel Lesiński’s29’s ImageOptim30 (and its command-line version31 is something you should definitely add to your build/back-end flow). By its very definition, lossless optimization doesn’t result in a quality loss, so this is something you should always add to your image processing pipeline. It is also important to always add it as the last phase of the image processing pipeline, since some of the other tools may add some useless noise to your images that lossless compression will get rid of.
The best tool for lossy compression? Well, that depends on the format.
For the common case in which the image you want to optimize is a JPEG, you can apply moderate and controlled form of lossy optimization by running through a script called cjpeg-dssim32, a script that runs the JPEG multiple times through a highly optimized encoder called MozJPEG33, making sure that the level of compression applied will only have a very small visual effect. In the future, MozJPEG may get that functionality integrated into the encoder, eliminating the need for an external script.
If the image you have on your hands is a PNG, your best bet is to run it through a lossy optimizer such as ImageAlpha34, or the command-line equivalent PNGQuant35, to reduce its number of colors or its precision, and thereby its byte size.