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.
The trouble is, browsers are really aggressive about downloading assets like images. That’s good, as it’s why the web (can be) as fast as it is. But is also means that we need to provide a bunch of information about our images right in the HTML. Can’t a browser just know how big an image is? Sure it can, after it has downloaded it. Can’t a browser know how big an image is going to be shown on the page? Sure it can, after it’s downloaded all the CSS and performed layout. The responsive images syntax tries to get ahead of all that by providing that information right in the syntax. Figuring out that syntax is tricky! There is srcset, sizes, and the <picture> element, and there is a ton to wrap your mind around there.
It gets more complicated still.
The syntax you need to build is based around having multiple copies of that image in which to build the syntax around. How do you make them? How many should you make? What size should they be?
Fortunately, there is some automated tooling popping up around responsive images. WordPress was an early player. Out of the box, WordPress will create multiple versions of the images you upload and output <img> tags with a helpful srcset syntax. But you can do much better. You can provide a sizes attribute that actually matches what your theme is doing and how it’s sizing those images.
Also, WordPress doesn’t use any special intelligence for creating multiple copies of the images you upload. But, it could. A tool like the responsive image breakpoint generator does use some intelligence for figuring out how many different images you can make, so you can strike a balance between having close to the perfect image for the job and not needing to make hundreds or thousands of copies of it. That tool has an API!
It gets more complicated still.
Different browsers support different image formats. For example, WebP. There are performance savings to be had by serving the right image format to the right browser. The responsive images syntax can help with that, but it complicates the syntax. Many image formats have a notion of quality as well. What quality do you save these multiple copies at?
At this point, it’s a good time to mention Cloudinary. I’ve got it integrated right now on CSS-Tricks, and it helps with a lot of this stuff. I should mention that I’m a paying Cloudinary customer, and this screencast was not sponsored, but Cloudinary has sponsored CSS-Tricks in the form of two highly related sponsored posts:
- Responsive Images in WordPress with Cloudinary, Part 1
- Responsive Images in WordPress with Cloudinary, Part 2
In a nutshell, here’s how it all works on CSS-Tricks now:
- I upload images just like I always would with WordPress.
- Rather than the
srcsetinformation being generated with WordPress, it’s generated by this smarter API. - The image is also uploaded to Cloudinary.
- When WordPress filters and outputs the HTML for the images, all that good
srcset(and customsizes) data is applied. The URL’s point to Cloudinary URLs. - The Cloudinary URL’s make use of Cloudinary’s ability to automatically adjust both the format and the quality automatically (using their fancy technology) to make sure things are the best they can be for the particular browser requesting the image.
- Old images that weren’t uploaded to Cloudinary originally still benefit from all the Cloudinary goodness. They don’t have as smart of
srcsetdata, but they still use “fetch” URL’s meaning they can benefit from auto formatting and auto quality (which is probably a decent bit of the performance improvement, anyway).
In short, not only am I using responsive images here on CSS-Tricks to help with performance, the Cloudinary integration seriously ups that game.
I’m also happy that this isn’t a hard dependency. If the Cloudinary plugin is ever shut off, everything just goes back to normal WordPress responsive images.
