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.