Safari 11.1 shipped a strange-but-very-useful feature: the ability to use a video source in the
<img /> tag. The idea is it does the same job as a GIF (silent, autoplaying, repeating), but with big performance gains. How big? "20x faster and decode 7x faster than the GIF equivalent," says Colin Bendell.
Eric Portis joins me to dig into the world of responsive images.
We start at the basics. Responsive images are specifically images in HTML and exist because of a desire for better performance. Images are probably the biggest culprit in the overall weight of websites. If we can avoid sending too many pixels across the network, we should. After all, a screen that is only 720 pixels wide doesn't need a 2000 pixel wide image, even if it's a 2x display.
In Part 1 of this series, I provided some background on responsive images, describing how you can add
sizes attributes to an
img element to serve appropriately sized image files to users of a website based on the size and capabilities of their browser and device. I also shared how WordPress used its native image resizing functionality to implement
sizes automatically and how you can use an external image service like Cloudinary to extend the native implementation that WordPress provides.
Perhaps you've heard about the WebP image format? And how it's a pretty good performance win, for the browsers that support it? Well that's only for Blink-based browsers, at the moment. Estelle Weyl's article Image Optimization explains the best image format for each browser:
|Browser||Optimal image format|
|IE 9+ / Edge||JPEG-XR|
And you can serve these formats through the
<picture><source type=""> syntax.
Couple that complexity with the complexity of responsive images, and it really seems like outsourcing image delivery to a dedicated service seems like the way to go. At least above a certain scale.
No surprise to any of y'all: screens come in a whole lot of different sizes and pixel densities these days. The technology behind dealing with that is catching up. For example, responsive images. So, we need software to help us generate those many versions of images we need.
Thankfully, all the most popular design software is starting to accommodate that need. Adobe Photoshop, Adobe Illustrator, Sketch, and Affinity Design all have pretty solid workflows for doing just that. I cover all those in this post over on the Media Temple blog.
I'm guilty of using responsive images by taking a high res image and downsizing it a few times kinda randomly and using those as the srcset images. Basically the same "desktop", "tablet", "mobile" thinking I can also be guilty of with breakpoints.
Soooo what is the perfect way to do responsive images? Ideally we'd be sending the exact image that any device needs. If a device/browser/design combination requires an image to be 457px wide, in a perfect world, we'd send it a 457px wide image. But it's impractical (from a lot of perspectives: creation, storage, caching) to make "one image per possible pixel width".
There is a happy medium here. The Responsive Image Breakpoints Generator says:
Responsive websites, even the most modern ones, often struggle with selecting image resolutions that best matchthe various user devices. They compromise on either the image dimensions or the number of images. It's time to solve these issues and start calculating image breakpoints more mathematically, rather than haphazardly.
It takes information like your breakpoints, your resolution needs, a reasonable change in file size between versions, and the image itself to create a all the images (and responsive images markup) you need to get to this happy medium.
Nadav Soferman has written a great post about the common mistakes that can be made when developers attempt to make images responsive:
Whichever responsive design solution or framework you choose, you still need to generate and deliver multiple versions of each image. The challenge of finding the best fitting resolutions, which are the responsive breakpoints for each specific image, is common for all approaches and frameworks.
What’s especially surprising to me is we need to serve a different number of scaled images depending on the image itself in order to get the best performance gains possible. One image might require five versions whilst another might require nine.
Nadav also walks us through a new tool called Responsive Breakpoints which has been designed to solve a lot of these common mistakes. If we upload an image the app will let us download the scaled-down images, show us which are the optimal breakpoints for that particular image, and will then give us a clear example with markup so that we can add it straight into our designs.
This tool handles the image creation and
srcset attribute creation, but I've also dreamed of an automated tool for
sizes attribute creation. For example, the page you intend to use the image on loads up in an iframe. The iframe resizes around a bunch, watching what happens to the width of the image and recording the dramatic shifts (which are likely breakpoints). Then it intelligently creates the sizes attribute based on that information. #HotAppIdea. Which also reminds me of how nice it would be to set a
<meta> tag with sizes information, since designs change.
In April 2014 Tim Evko created a WordPress plugin that used the CMS's capabilities to make using responsive images much easier (just do what you were already doing, reap benefits). He wrote about it here. Later it became the official plugin of the RICG. Now a year and a half later it was merged into WordPress core (meaning when v4.4 drops, it will be in there).