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.
Now there are challenges with this approach:
Client Hints To The Rescue
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.
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”>
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:
: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.