If you’re reading this, you’re probably already familiar with responsive images. Even so, it may be helpful to have a little background. (Then we’ll get to the WordPress part, and how to make them even better with Cloudinary.) For most of the Web’s existence, any time you wanted to include an image on a web page, you would create markup that looked like this:
<img src="/path/to/my/image.jpg" alt="a very nice image">
In this example, the
<img> element references a single image file named `image.jpg` located on a server at `/path/to/my`. This markup is straightforward in that it tells the browser to download and render a specific image file, referenced by the
src element, onto the web page.
This arrangement was fine until 2010, when Ethan Marcotte published his seminal article, Responsive Web Design, which popularized the technique of using Cascading Style Sheet media queries to modify the layout of web pages to fit whatever size device a person is using. Responsive web design also increased interest in optimizing the performance of websites based on screen size. This focus made clear just how big a pain point images are for performance, accounting for most of the bytes included on each web page. With responsive design, developers began to send images that look beautiful on large desktop displays to all users, which resulted in sending extra bytes to smaller mobile devices, making the mobile browsing experience much slower than necessary.
An intrepid group of web developers, known as the Responsive Issues Community Group (RICG), set out to fix this problem by introducing new HTML so that developers could identify different image sources for a web page based on contextual information like screen size. Here’s an example of one of the new markup patterns:
<img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" sizes="(min-width: 36em) 33.3vw, 100vw" alt="A rad wolf">
In this example, the
<img> markup now includes two new attributes: a
srcset, which contains a list of image files and their corresponding pixel widths, and
sizes, which gives the browser an estimate of the image’s intended layout size, depending on certain media query conditions. The src attribute is included to serve as a fallback for older browsers that don’t support the new
This new markup allows browsers to determine and download the image that’s most appropriate, saving bytes (and time) for users. For a deeper dive into this and other responsive image markup patterns, I strongly recommend reading Jason Grigsby’s Responsive Images 101 series.
Responsive Images in WordPress
At the end of 2015, in partnership with members of the RICG, WordPress shipped version 4.4, which included native support for responsive images. WordPress 4.4+ automatically generates
sizes attributes for images included in a post or page. The WordPress implementation uses already-available image resizing functionality to accomplish this task. Before version 4.4, WordPress already created several smaller versions of any image uploaded to your media library. Since version 4.4, WordPress uses those additional sizes to create
srcset attributes so that people visiting your site can benefit by downloading an image file that is no larger than what they need.
This implementation works well out of the box but has a few limitations. For instance, WordPress creates image size variations at the time the original is uploaded, which means that only image sizes that are defined at that point will be available in
srcset attributes. In addition, image processing can overtax the resources available on many shared hosting plans, so WordPress has to be conservative about how many variations of each image it creates by default.
Ideally, you could dynamically create image sizes when they’re needed for your layouts and offload the processing to an external image service. Fortunately, services like Cloudinary exist, which do exactly this. I’ve been impressed with the work Cloudinary has been doing in the image management space, so I was wanted to see how I could use the service to extend the default responsive image implementation in WordPress.
Using Cloudinary to Extend WordPress
Cloudinary provides tools to perform several image transformations besides simple resizing, and it has published its own WordPress plug-in to the WordPress.org plug‑in repository. The plug‑in doesn’t yet support responsive images out of the box, so I wanted to see if I could make a slimmed-down plug‑in using its Image Upload application programming interface. My goal was to sync images from my media library to Cloudinary’s service and have Cloudinary automatically create the image sizes needed to serve responsive images from its content delivery network (CDN).
I’ve created a demo plug‑in, which I have published to GitHub, so that you can check it out. In a follow-up article, I’ll explain more of the technical details and design decisions of the plug‑in, but for now I’ll describe what the plug‑in does at a high level.
First, when you add an image to your WordPress media library, WordPress uses Cloudinary’s PHP integration library to upload that image to Cloudinary and task its service with creating alternative image sizes to be used in the
srcset attribute. Where this gets interesting is that Cloudinary has developed a unique responsive image breakpoint solution that automatically calculates the optimal image sizes needed based on the content of your image.
Once the image is uploaded to Cloudinary, the service returns data associated with the newly created image sizes to your WordPress site. By making use of WordPress filters, we can use that data to build
srcset attributes for our images that reference the files from the Cloudinary CDN rather than locally hosted images.
By combining the simplicity of the WordPress native responsive image functionality with the image management tools that Cloudinary provides, you can manage your content exactly how you want while providing visitors to you site with images that are automatically optimized for the capabilities of their device, without having to worry about each image added to your site individually. In my next article, I’ll dive into the specifics of the code I developed for my plug‑in. For now, I hope you can see how powerful combining WordPress with services like Cloudinary can be.
This post (and the plugin!) was written by Joe McGill.
- An Intro to Responsive Images and WordPress (you are here!)
- A WordPress Plugin integrating Cloudinary and Responsive Images
Cloudinary can help with responsive images on the web in a big way! They not only can create the different sizes of images needed to send the best possible size, but they can send it in the right format and even completely automate the process, for any application.
We’re working on getting Cloudinary integrated here on CSS-Tricks. I’m pretty stoked about it as it should be a good performance gain (which we are carefully tracking). To put a point on it, this is how it will be an upgrade to the responsive images that WordPress is already doing:
sizesattribute customized to this exact site and situations.
Cutting edge. Thanks!
Just curious if I got the gist of this right. I’m mostly a noob to image control, and would love to share with others (accurately)…
First, I got the CDN itself will make our WP sites load faster. More so than the new WP capability that srcset does with files internal to the WP host itself. Second, I got that your plug-in code aims to create more possibilities/decision points/img files. This data doesn’t go on the WP server, but on a separate image-hosting CDN (or maybe I’m thinking AWS S3?). I see the game-changing happens when this coupling speeds mating better with the end device needs (in lieu of the end device using limited onboard WP srcsets). It also offloads tremendous work on WordPress itself if all the sources were on the WP server (which is why WP doesn’t auto generate too many possibilities as you said above).
Did I get it right? If you respond, thanks in advance. Off to make this gem work now…
So, is Cloudinary with this plugin better than Jetpack Photon?
I didn’t do any side-by-side comparisons while working on this. If that’s something you want to check out and report back, it would be interesting.
It would be great to see a follow up article Chris about any issues that you ran into. I started to do the same but I found a lot of my work on the site was commuting to and from work on my local machine.
Any tips… or tricks if you will… to keep a local set of images for local development and the cloundinary for production would be most welcome :)
Other than that I found it to be a great addition to the site and site performance.
Nice coverage. So, your next episode will cover implementation completely? Thanks.
I am surprised there is no consideration for offloading this work to the client (ie, browser/js) to do the image resizing and then pass this on to your server. (ie, no work needed by WP or your own server at all)
Secondly, my understanding is that a CDN is useful mainly because if a visitor to your site loads a resource (from your site) that is from a CDN, they may have it cached already.
Therefore, if the content (ie, the responsive images in question) for one post/site won’t be loaded from any other place, I don’t see how a CDN would help with performance.
Anyone care to clarify the benefit of a CDN or 3rd party?
One big advantage to a CDN is that it provides localized data centers which are closer to the user and result in faster downloads.
Really nice. I’m been using Cloudinary as a CDN for many years. Will this work with the images already uploaded to Cloudinary?
btw, did a hack converting animated gifs to video: https://gist.github.com/soderlind/f0e0981a9ece9b41144f8fe22db23a6f