There are many times where web developers have to wrestle with forcing images into responsive layouts. Due to this media queries and fluid grids are constantly employed to achieve visually flexible images. Achieving such flexible images as pointed out by Ethan Marcotte in the seminal first edition of his book is as easy as:
To make this code work effectively, you need to make sure that the image resources being served must be big enough to fill large viewports and high-resolution displays. Not only simply setting width on images, you may need to resize the images as well, or else huge image resources will be sent to everyone which is a performance disaster.
Or you can use the suite of new HTML features as another way to combat images into responsive layouts. This allows images to transform in a way that allows users get tailored resources based on their context. These features provide adaptation via allowing authors to mark-up multiple, alternate resources like so:
This method can be tedious and complex for some people, since it always generates multiple alternate resources for every image. Cloudinary can help with the resource generation, but then the markup in our image tag will be overwhelming.
Considering JavaScript
The other method that developers usually use is by using JavaScript. JavaScript can directly measure the browsing context and when paired with on-the-fly, server-side resizing, it requests a single, perfectly-sized resource every time with little or no extra markup required. This post explains how to use JavaScript to achieve automatic responsive images.
Now there are challenges with this approach:
- Setting up JavaScript infrastructure which might be complex
- Inserting JavaScript between users and our page’s core content which might be tricky to do effectively.
- Browser vendors use the speculative pre-parser to shed off as many image loads as possible before a page’s HTML has even finished parsing. And for JavaScript to load measured image resources, it must wait for page layout to be complete before it can measure the page.
Due to this, we have two choices whether we wish to use JavaScript to load responsive images. Either :
- Let the pre-parser do its work and set JavaScript to double-load all of our images, or,
- Disrupt the pre-parser by authoring invalid src-less <img>s so that our JavaScript can start loading our pages’ images last, instead of first.
Client Hints To The Rescue
With the client hints, you don’t have to sweat yourself with all the options we considered above. In fact, you don’t need to use JavaScript anymore. The good news is that there is a fix! No, not throwing JavaScript at the challenge, but by asking the web server for a helping hand. Enter Client Hints, an initiative spearheaded by Google that is already available in browsers (Chrome and Opera) and that is super-simple to use. Let’s see how Client Hints can reduce both image size and verbosity of the responsive images markup.
Automatic DPR
In usual browsers you’ll see an image, the URL of which delivers different resources to different users, depending on their context. While in browsers that support Client Hints, 1x devices will receive 1x resources, 2x screens will receive 2x resources. This way is possible since a little tag is placed in the <head> of this page which looks like this:
<meta http-equiv=”Accept-CH” content=”DPR”>
You can use the code above to send an extra HTTP header named DPR, thus advertising devicePixelRatio. Those DPR HTTP headers are Client Hints. So, when you send DPR hints with a little meta magic and dpr_auto appended to the URL, Cloudinary is able to deliver different resources to different users depending on their display density.
Automatic Width
To fit different display densities, you can use code : dpr_auto scales images. Cloudinary provides w_auto which scales images to fit variable layout widths. You can take a look at the example below:
<meta http-equiv=”Accept-CH” content=”DPR, Width”>
[…snip…]
<img sizes=”100vw”
src=”http://res.cloudinary.com/demo/w_auto/on_the_phone_csmn8h.jpg”
alt=”Obama on the phone with Castro.” />
Here are some explanations about it:
- The meta tag instructs the browser to send another Client hint: Width in addition to DPR.
- The img tag includes a sizes attribute which informs the browser about the layout width of the image.
- The browser then broadcasts the width to the server via the Width hint.
Advanced W-Auto Usage
Let’s take a look deeper about Cloudinary’s w_auto parameter. W_auto can use two optional parameters like this:
http://res.cloudinary.com/demo/w_auto:100:400/bike.jpg
:100 shows Cloudinary how big the difference between alternate resources should be. By defining a rounding step between them, this parameter allows you to limit the number of possible responses. For instance, if the target width is 323 pixels, Cloudinary will round up to the nearest hundred and return a 400 pixel-wide resource. However, if you place the parameter to :1, resources will be scaled to match the layout width exactly which is generally not a good idea.
:400 refers to the fallback width. This parameter will be used to serve an image resource with that width, if a browser doesn’t need send a width hint. For instance, browsers that don’t support Client hints, and this fallback parameter too is absent, w_auto will deliver images at their original size, since it will be impossible to load higher pixels, such as 12 megapixels to a site.
