{"id":21406,"date":"2016-08-18T12:10:05","date_gmt":"2016-08-18T12:10:05","guid":{"rendered":"http:\/\/automatic_responsive_images_with_client_hints"},"modified":"2025-08-21T12:22:35","modified_gmt":"2025-08-21T19:22:35","slug":"automatic_responsive_images_with_client_hints","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/automatic_responsive_images_with_client_hints","title":{"rendered":"How to Scale an Image Automatically with Client Hints"},"content":{"rendered":"
\n

I\u2019ll start by giving it to you straight:<\/p>\n

As part of the recent \u201cauto\u2013everything<\/a>\u201d launch, we introduced two new transformation parameters \u2013 dpr_auto<\/code><\/a> and w_auto<\/code><\/a>, which pair the DPR<\/code> and Width<\/code> Client Hints with Cloudinary\u2019s existing image resizing and delivery infrastructure, in order to serve up simple, automatic responsive images<\/em>.<\/p>\n

If you\u2019ve spent any time wrestling images into responsive layouts you know that those words \u2014 \u201csimple\u201d, \u201cautomatic\u201d, and \u201cresponsive images\u201d<\/a> \u2014 are rarely found in honest proximity. So, take a quick peek at the demo<\/a> and allow me give you a glimpse into the future of images on the web.<\/p>\n

\nClient Hints live demo<\/a>\n<\/p>\n

Mo\u2019 resources, mo\u2019 problems<\/h2>\n

\"A<\/p>\n

Along with media queries and fluid grids, \u201cflexible images\u201d are one of the tentpoles of Ethan Marcotte\u2019s Responsive Web Design<\/a>. And, as Ethan pointed out in the seminal first edition of his book<\/a>, achieving visually<\/em> flexible images is as easy as:<\/p>\n

img<\/span> { max-width<\/span>: 100%<\/span>; }\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n
And so, along came a suite of new HTML features<\/a> which allow images to adapt<\/em>, ensuring that each user gets a resource that is tailored to their particular context. These features implement a key idea: authors should be able to mark up multiple, alternate resources<\/em>. These features let us transform this bit of ham-fisted responsiveness:<\/p>\n
<img<\/span> src<\/span>=\"enormous.jpg\"<\/span> \n     alt<\/span>=\"Worst-case performance scenarios for all\"<\/span> \/><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n
\u2026into an adaptable, multi-headed Hydra:<\/p>\n
<img<\/span> sizes<\/span>=\"100vw\"<\/span>\n     srcset<\/span>=\"tiny.jpg      320w,\n             small.jpg     512w,\n             medium.jpg    640w,\n             large.jpg    1024w,\n             huge.jpg     1280w,\n             enormous.jpg 2048w\"<\/span>\n     src<\/span>=\"fallback.jpg\"<\/span> \n     alt<\/span>=\"To each according to his ability\"<\/span> \/><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n
Considering JavaScript<\/h2>\n
One answer to that question \u2014 one that we have embraced and implemented<\/a> \u2014 is: use JavaScript.<\/p>\n
Our last example offered the browser an array of options, allowing it to pick the best resource for the current context. A smart bit of JavaScript can directly measure<\/em> the browsing context, and \u2014 when paired with on-the-fly, server-side resizing \u2014 request a single, perfectly-sized resource every time, with little or no extra markup required.<\/p>\n
But\u2026 There are some problems with this approach. First, it requires setting up some JavaScript infrastructure, which is a complexity of a different flavor. Second, we\u2019re inserting JavaScript between users and our pages\u2019 core content<\/em>, which can be tricky to do well<\/a>. Worst of all, though \u2014 as it turns out \u2014 the smart people that make browsers for a living have noticed that images account for 64% of the web\u2019s bytes<\/a>, and they have gone to Herculean lengths to get those bytes across the wire as quickly as possible. Their main tool in that quest: the speculative pre-parser<\/a>. In a nutshell, it tries to kick off as many image loads as possible[1]<\/sup><\/a> before a page\u2019s HTML has even finished parsing<\/em>. This results in an enormous 20% speed boost<\/a>, and an intractable problem, when it comes to responsive images<\/a>.<\/p>\n
You see, for a JavaScript to load made-to-measure image resources, it must first measure the page \u2014 which means waiting until page layout is complete. This happens long after the pre-parser has raced through the HTML, kicking off image loads with wild abandon. This means that if we wish to use JavaScript to load responsive images, we face a choice. We must either:<\/p>\n
    \n
  1. let the pre-parser do its thing, and, after a lengthy delay, set our Javascript loose to double-load all of our images, or,<\/li>\n
  2. sabotage the pre-parser by authoring invalid, src<\/code>-less <img><\/code>s so that our JavaScript can, after that same delay, start loading our pages\u2019 images last<\/em>, instead of first<\/em>.<\/li>\n<\/ol>\n
    Both options present significant compromises; both set us back from achieving our over-arching goal, which is not, after all, simply to load appropriately-sized images. Our larger goal is performance<\/em>.<\/p>\n
    Enter Client Hints<\/h2>\n
    \"A<\/p>\n
    So, where does that leave us? Performant, flexible images are inherently complex; marking up multiple, alternate resources can get verbose and complicated; trying to solve the problem with Javascript is fraught with compromise. What other tools do we have at our disposal? Where else can we shift the burden of this complexity?<\/p>\n
    The idea of Client Hints is: let\u2019s put it on the server! If you\u2019re a front-end developer, Client Hints means making responsive images somebody else\u2019s problem.<\/em> Cloudinary\u2019s pitch to you, front-end-developer, is: make responsive images our<\/em> problem! Leverage our Automatic Width and Automatic DPR features and we\u2019ll handle this stuff so that you don\u2019t have to.<\/p>\n
    How to Change Resolution of Image With Automatic DPR<\/h2>\n
    Here\u2019s a simple, live example:<\/p>\n
    \n      Loading code examples<\/span>\n    <\/cld-code-widget>\"Live<\/a><\/p>\n
    The above URL delivers different resources<\/em> to different users<\/em>, depending on their context.<\/em> In browsers that support Client Hints<\/a> (at the moment, that\u2019s mostly just Chrome), 1x devices will receive 1x resources; 2x screens will receive 2x resources. The above URL responds to varying DPRs automatically.<\/p>\n
    How? There\u2019s a little tag in the <head><\/code> of this page which looks like this:<\/p>\n
    <meta<\/span> http-equiv<\/span>=\"Accept-CH\"<\/span> content<\/span>=\"DPR\"<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n
    Why else might we want to vary the scale of a resource in response to a fact about the browsing context? I\u2019ll tell you why: to fit flexible, responsive layouts!<\/p>\n
    How to Scale an Image with Automatic Width<\/h2>\n
    Just like dpr_auto<\/code>, w_auto<\/code> sends different users different resources from the same URL. But whereas dpr_auto<\/code> scales images to fit different display densities, w_auto<\/code> scales images to fit variable layout widths. In its simplest form, w_auto<\/code> looks like this:<\/p>\n
    <meta<\/span> http-equiv<\/span>=\"Accept-CH\"<\/span> content<\/span>=\"DPR, Width\"<\/span>><\/span>\n\n[\u2026snip\u2026]\n\t\n<img<\/span> sizes<\/span>=\"100vw\"<\/span>\n     src<\/span>=\"https:\/\/res.cloudinary.com\/demo\/w_auto\/bike.jpg\"<\/span> \n     alt<\/span>=\"Smiling girl with a bike.\"<\/span> \/><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n
    What have we done here?<\/p>\n
    First, we\u2019ve used our meta<\/code> tag to opt the browser into sending another Client Hint along with its requests: Width<\/code>.<\/p>\n
    Finally, note that I didn\u2019t<\/em> include dpr_auto<\/code> in the URL. I didn\u2019t have to! If we opt into sending both DPR<\/code> and Width<\/code> Hints in the meta<\/code> tag up top, w_auto<\/code> images will be scaled based on both of them.<\/p>\n
    So \u2014 that\u2019s w_auto<\/code> at its simplest; in Chrome, it just works. But, especially if you\u2019re using the feature in production, you should dive a little deeper.<\/p>\n
    Advanced w_auto usage<\/h2>\n
    \"Now<\/p>\n
    w_auto<\/code> can take two optional parameters:<\/p>\n
    \n      Loading code examples<\/span>\n    <\/cld-code-widget><\/p>\n
    \"Responsive<\/a><\/p>\n
    The first (:100<\/code>) tells Cloudinary how big the \u201cjumps\u201d between alternate resources should be. If you set this to :1<\/code>, resources will be scaled to match the layout width exactly<\/em> \u2014 which as it turns out, is a bad idea. To deliver perfectly-scaled resources, our servers must render and store hundreds, maybe thousands<\/em> of alternate versions of your image, which is both computationally expensive and<\/em> terrible for your pages\u2019 performance. More, alternate resources means fewer cache hits<\/a>, and a hit at any level \u2014 in the local browser cache, on the CDN, or server-side \u2014 will always be significantly<\/em> faster than a miss. Thus, this first parameter allows you to limit the number of possible responses by defining a \u201crounding step\u201d between them. For example, here, if the target width is 452 pixels, Cloudinary will round up to the nearest hundred and return a 500-pixel-wide resource.<\/p>\n
    The second parameter (:400<\/code>) serves as a fallback Width<\/code><\/em>, which will be used if the browser doesn\u2019t send a Width<\/code> Hint. In this example, browsers that don\u2019t support Client Hints are served a 400-pixel-wide image. (400<\/code> is a \u201cmobile-first\u201d default. If you would rather serve a \u201cdesktop-first\u201d default to non-supporting browsers, set this to something higher, like 1000). Word to the wise: without a Width<\/code> or this fallback, w_auto<\/code> images will be delivered at their original size<\/em>. If you\u2019re working with large originals \u2014 especially given Client Hints\u2019 nascent support \u2014 this could be disastrous! You do not<\/em> want to start sending 12 megapixel originals to Mobile Safari.<\/p>\n
    There is one more thing to know about these parameters; I\u2019ve saved w_auto<\/code>\u2019s best trick for last.<\/p>\n
    Automatic breakpoints<\/h2>\n
    Picking an arbitrary step-size using the first parameter can feel, well, confusingly arbitrary. Four years ago, Jason Grigsby pointed out<\/a> that it makes more sense to think about these steps in terms of bytes<\/em>, rather than pixels<\/em>. We agreed, and built a tool that implements Jason\u2019s idea \u2014 the Responsive Image Breakpoints Generator<\/a>. We\u2019ve now built that same logic into w_auto<\/code>.<\/p>\n
    Our servers can look at your images, see how they compress, and determine byte-size-based gaps between images for you<\/em> if you set the steps parameter to a special value: :breakpoints<\/code>.<\/p>\n
    w_auto:breakpoints<\/code> packages up a lot of smart thinking and builds on years\u2019 worth of foundational effort to provide an astoundingly automatic responsive images solution that\u2019s smart not only about images\u2019 context<\/em> \u2014 but also their particular content<\/em>. Alas, :breakpoints<\/code> requires a bit of gymnastics at the CDN layer, and in order to use it you\u2019ll need to set up either a custom domain name<\/a> or<\/em> a private CDN distribution \u2014 features which are available only on Advanced or Enterprise\/Custom Plans<\/a>. Contact us<\/a> if you\u2019re interested in setting up :breakpoints<\/code> on your account.<\/p>\n
    Speaking of the imperfect present\u2026<\/p>\n
    Let\u2019s talk about Client Hints\u2019 browser support<\/h2>\n
    \"A<\/p>\n
    Right now, Client Hints are only supported in Chrome and Opera<\/a>. That means that dpr_auto<\/code> and w_auto<\/code> will work for approximately half of your users[3]<\/sup><\/a>.<\/p>\n
    Other browsers have been<\/a> slow<\/a> to<\/a> follow Google\u2019s lead. Like every new web platform feature, Client Hints faces a chicken-and-egg problem. Vendors don\u2019t want to implement features in browsers until they see a clearly-expressed demand; authors don\u2019t want to use features on their pages until they enjoy almost universal support.<\/p>\n
    dpr_auto<\/code> and w_auto<\/code> are, among other things, our attempt to nudge Client Hints forward. We developed these features and are advocating for their adoption because we believe fully-automated, drop-dead simple, responsive, and performant images should not be the exception, but rather the norm.<\/p>\n
    So, should you use them?<\/h2>\n
    If you\u2019re starting a new project or retrofitting an old one, doing something<\/em> about responsive images should be at the top of your to-do list. If you\u2019re willing to put in the effort, a markup-based solution will get you the most browser support, but automating<\/em> that markup can be complicated. JavaScript-based solutions are simpler, but operate within significant performance constraints.<\/p>\n
    Client Hints pave a third path, which is both simple and performant<\/em>. And, despite browsers\u2019 uneven Client Hints support, w_auto<\/code> and dpr_auto<\/code> provide a lot of value, right now.<\/p>\n
    The vast<\/a> majority<\/a> of websites aren\u2019t doing anything about responsive images; most developers are still sending a single, wasteful, high-resolution resource to everyone. Implementing dpr_auto<\/code> and w_auto<\/code> requires next-to-no effort and delivers fully-responsive images to around half of your visitors without negatively impacting the other half. They provide tremendous performance gains now, and those gains will grow as browser support improves.<\/p>\n
    Client Hints are where the puck is going for images on the web. Sign up for a free account<\/a> and start using them, today.<\/p>\n
    Further reading<\/h2>\n
    2,000 words in and you still want more? I encourage you to dive into the following resources:<\/p>\n
    Next, note that our img<\/code> includes a sizes<\/code> attribute<\/a>. This attribute tells the browser the layout width of the image [2]<\/sup><\/a> The browser then broadcasts that width to the server, via the Width<\/code> hint. No sizes<\/code>, no Width<\/code>. No Width<\/code>? w_auto<\/code> does nothing. So (besides the opt-in meta<\/code> tag), this is the one additional thing that w_auto<\/code> asks of you: for it to work, you\u2019ll have to stick sizes<\/code> on your img<\/code>s.<\/p>\n
    That tells the browser to tack an extra HTTP header named DPR<\/code> onto all of its subsequent requests, advertising the current devicePixelRatio<\/code><\/a>. Those DPR<\/code> HTTP headers are Client Hints. And smart servers can use them to tailor custom, smart responses. And so, when we opt-in to sending DPR<\/code> Hints with a little meta<\/code> magic, and add dpr_auto<\/code> to our URL, we\u2019re able to deliver different resources to different users depending on the density of their display.<\/p>\n
But this adaptability comes at a price, paid in complexity. Generating, managing, and marking-up two or three (or six) \u201cmultiple, alternate\u201d resources for every image can be both tedious and fiendishly complex<\/a>. Services like Cloudinary can automate the resource generation<\/em> side of the equation<\/a>. But what to do about all of that markup?<\/p>\n
For that rule to work though, the image resources backing it up must be big enough to fill large viewports and high-resolution displays. Shoving single-src<\/code> images into responsive layouts means sending gigantic<\/em> resources to everyone<\/em>. Which is a performance disaster<\/a>.<\/p>\n