{"id":21525,"date":"2017-05-23T21:54:03","date_gmt":"2017-05-23T21:54:03","guid":{"rendered":"http:\/\/imagecon17_delivering_responsive_images"},"modified":"2023-05-18T09:56:09","modified_gmt":"2023-05-18T16:56:09","slug":"imagecon17_delivering_responsive_images","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images","title":{"rendered":"ImageCon17: Delivering Responsive Images"},"content":{"rendered":"<div class=\"wp-block-cloudinary-markdown \"><div style=\"position:relative;padding-bottom:50%;padding-top:30px;height:0;overflow:hidden;\">\n  <iframe style=\"position: absolute;\n        top: 0;\n        left: 0;\n        width: 100%;\n        height: 100%;\"\n        src=\"https:\/\/www.youtube.com\/embed\/dJDoPFbcJR4\" frameborder=\"0\" allowfullscreen>\n  <\/iframe>\n<\/div>\n<h2>Talk Summary<\/h2>\n<p>It took nearly four years, four proposed standards, the formation of a community group, and a funding campaign to pay for development, but we finally got what we\u2019ve been clamoring for\u2014a solution for responsive images baked into browsers. Now the hard work begins.<\/p>\n<p><a href=\"http:\/\/twitter.com\/grigs\">Jason Grigsby<\/a> is co-founder of <a href=\"https:\/\/cloudfour.com\/\">Cloud Four<\/a>, a small web agency in lovely, Portland, Oregon. He co-authored Head First Mobile Web for O\u2019Reilly, was part of the team that worked on the Obama \u201908 iPhone app, founded Mobile Portland along with the first open device lab; and was a signatory to the Future Friendly Web manifesto.<\/p>\n<p>When he was young, Jason whistled at 1200 baud, was utterly unimpressed when first introduced to Mosaic, and was bit by the mobile bug in 2000 when WAP was crap. He participated in the Responsive Images Community group and has written numerous articles on how to use responsive images. He is currently obsessed with the potential of Progressive Web Apps.<\/p>\n<h2>Responsive images have finally landed<\/h2>\n<p>After five years many specifications, some inflamed Twitter battles and other conversations, <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> have finally landed and there\u2019s a sound. Which is really exciting right? People have been climbing for this for quite some time and we\u2019ve reached a point where they\u2019re available in modern browsers. So people were excited, they wanted to go use them it\u2019s something that designers and developers have had as a point of frustration for a long time.<\/p>\n<p>And yet, as I watch the reaction to it it actually reminds me of my favorite cartoon character, Wile E. Coyote. I love Wile E. Coyote for many reasons. He persists right? Persistence is a big thing right now. Persistence and chasing the Road Runner, despite the fact that he never catches the Road Runner, except for one time which is I think something that people don\u2019t know. In 1980 in a cartoon called Soup or Sonic, Wile E. Coyote finally catches the Road Runner after 51 years of chasing him, failed attempts. And I want to show you that moment right now.<\/p>\n<p>Yeah! 51 years!<\/p>\n<p>So I do feel like this is what web designers and developers felt like after years of looking for something and some sort of solution for <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. And then all of a sudden they start looking at it and they\u2019re like \u201cWhat hath we wrought.\u201d Right? Like look at all this mark up this is a huge huge Road Runner that we\u2019ve just caught. And you see this in the comments on blog posts where people talk about \u201cThis is way too complex. Can you imagine doing this for 300 images?\u201d Or \u201cThere\u2019s so many things wrong with these new <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> systems. I don\u2019t have the time to enumerate the numbers of ways in which this is wrong.\u201d Right? Like this was the reaction and I get it. I get it because I mean who can forget how complex background gradients were and gradients were and the fact that they were so complex meant that they never got adopted and we just don\u2019t use CSS gradients on the web.<\/p>\n<p>Actually we do, right? Like we do end up sort of absorbing this complexity. And I think that our sort of gut reaction and pushback on images is not because it\u2019s complex because any time there\u2019s new mark up it takes us time to learn that mark up. I think it comes from the fact that we think of images as being very simple. And images have never been simple. They\u2019ve been difficult since the earliest days of the web. Back when we first started designing for the web we had to worry about the 216 web safe colors that were in the shared color space between Windows and Mac and we had to make sure that the images fit inside that color space or they wouldn\u2019t show up correctly. This prompted Lynda Weinman of Weinman.com to write a book in 1996 on how to deliver images through the web. It was 258 pages.<\/p>\n<p>The next year that wasn\u2019t sufficient so she created a second edition that was 447 pages. She went from this to building Lynda.com and selling it for millions of dollars or billions of dollars to LinkedIn. So I\u2019m hopeful that this is where I launch that same billionaire path, right here. But images have always been complex. Even now, the way in which our images compress and the fact that they compress differently based on whether there\u2019s a lot of visual gradation or differentiation from line to line whether it\u2019s vertical or horizontal makes a big difference.<\/p>\n<h2>Use Cases<\/h2>\n<p>So we have to accept that things are a bit more complex. But what I want to do today is I want to talk about the tools that you can use to make decisions about how your images should work and how to pick the right tools from sort of the set of <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> that we\u2019ve got available to us. In order to do that we have to talk first about some use cases. So the <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> community group which worked on this created a series of use cases related to <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> but I really just narrow it down to two.<\/p>\n<h4>Resolution switching<\/h4>\n<p>The two use cases that I think matter the most are resolution switching, and this is the idea that you\u2019ve got a single image and you want to display it at different sizes based on the size of the view port, based on the design, based on display density. Those sorts of characteristics. But the image itself is essentially the same.<\/p>\n<h4>Art direction<\/h4>\n<p>The second use case is what we call art direction, and there are a couple different examples of this. For example, this photograph of President Obama was taken as after the auto bailout he\u2019s talking about the success of the auto bailout. So if we\u2019re in a large enough screen it makes a lot of sense to show that background, to know that he was speaking at a factory. But if we simply shrink that image down it becomes really hard to recognize who\u2019s speaking. We\u2019d be much better off if we actually cropped closer to the speaker so that you could actually make out the details. So that\u2019s one form of art direction. But it doesn\u2019t have to be cropping.<\/p>\n<h4>Not simply cropping<\/h4>\n<p>This is the Nokia browser site. It actually launched the same week as the Boston Globe site and I consider it one of the seminal pieces of <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive design<\/a> work.<\/p>\n<p>The designers Bryan and Stephanie Rieger talked about how they wanted to be able to show off the chrome of the Nokia browser. So when they were on a wide enough screen they used a landscape version of the image, right? They wanted to be able to show off all of those pieces. But as that image shrunk down that version would get so small that you couldn\u2019t see the chrome. You couldn\u2019t see the details, and so they ended up creating a portrait version that was cropped. So that\u2019s another version of art direction.<\/p>\n<h4>Art direction: Images with text<\/h4>\n<p>The most common art direction examples we see are things that have text embedded inside images. So CB2 has this image from their home page from a little bit ago where they\u2019ve got three photographs on widescreens along with the stamp and some text and a couple of logos but on small screens they swap it out to just two photographs and just the logos, none of the text. If they shrunk it down it would get too small. Now this isn\u2019t a <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive design<\/a> but you can see how they would have to change the image on small screens. Free People is a shopping site that spends a lot of time on art direction. Every single day they have new imagery on their site. It\u2019s kind of insane what they do. And because of that they can\u2019t actually afford to spend the time to figure out how to overlay text on their images. So they create these new images on a daily basis but if they simply shrunk it down you wouldn\u2019t be able to read the text so they create an alternate version of the image. And we know that you couldn\u2019t read the text because if you actually click on that photo or tap on that photo you get taken to this page where they actually did just shrink it down and you can\u2019t read it.<\/p>\n<h2>&lt;img&gt; is always required<\/h2>\n<p>So despite the fact that they do it differently on their homepage actually on the actual catalog page they\u2019re actually showing this problem. So these are the two use cases. 90 percent of the time the use case that people have is the resolution switching use case. So I want to talk a bit about how you decide when you\u2019re going to use which responsive image standard. So first we\u2019re going to start with an image element. An image element is always required. The way that I think about the image element is that it\u2019s a box in to which all of these new responsive image standards go into. Whether it\u2019s picture or source set or sizes, whatever those rules are that are applied, they\u2019re always actually going to end up on the image element. As a matter of fact you can see this in JavaScript if you look at the source attribute and watch the current source change as you\u2019re in this case as the picture element is being applied, the media queries in the picture element are being applied.<\/p>\n<p>Now the first question I ask is if you\u2019ve got an image element do you need anything else? And if you have a fixed width design, you don\u2019t, right? The image element is sufficient. Or in some cases even in a <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive design<\/a> this is Rainbow Nursery, this really great and beautiful UK nursery. They\u2019ve got a great design and in the <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive design<\/a> they have the sorts of things that we see on many sites, right? The little icons at the bottom representing all the social feeds. Now three of the icons are SVG, one of them is a PNG. None of them are significantly different from the smallest version to the largest version. And in that scenario we only need one source.<\/p>\n<h2>srcset<\/h2>\n<p>Where things get different is when we start looking at high density displays, right? And this is where <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> comes in comes in, the ability to define multiple sources. So <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> adds as an attribute to the image element, a comma separated list of sources. And one of the first versions of it for dealing with high density displays is dealing with what they call \u2018x\u2019 descriptors or display density descriptors and so in this case we\u2019ve got two images. One that\u2019s a 1x image, one that\u2019s a 2x image and basically the browser selects based on the display density. Easy right? Well then we get into things like this. Now this page has a huge image. It\u2019s actually 256k at 1x and 508k at 2x. So if that\u2019s all we provide that\u2019s going to be far too large for somebody on a mobile device. We need more source files. Thankfully <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> actually solves this as well. So we have the ability to define a series of images and tell the browser what the width of those images are.<\/p>\n<p>Now what\u2019s important about this is that it\u2019s different than the way that usually happens in CSS where we\u2019re defining images based on what the size is and the page. This is actually the size that you would see if you opened it in Photoshop or an image editor and it asked what are the raw pixels of this image. And then the browser will pick the best source from that. Which begs the question, really right, like how will the browser pick the best source? And this is where we get into the area that made <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> really challenging.<\/p>\n<h2>How will the browser pick the best source?<\/h2>\n<p>So if we look at sort of a typical web page and the way it loads one of the things you\u2019ll see is that the HTML is requested and then the HTML returns and you see parsing starting on that and then as the browser parses that HTML it finds a CSS in JavaScript and it asks for those things to go, it requests those items. But then shortly thereafter images are requested, and more images are requested and so it\u2019s receiving data about the images more information\u2019s coming in from the JavaScript and the CSS and much much later in this timeline is actually when we see layout being calculated. When we actually get the CSS process to know what\u2019s going on on the page. And this is important because the images are downloaded before the size of the image and the page is known. And that\u2019s the big problem.<\/p>\n<p>If we go back to this example, how do we know which of these sources we should grab if we don\u2019t yet know what the size if of the image and the page when it\u2019s downloading? A lot of sort of simplistic versions of <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> simply look at the size of the view port and think hey if we know the size of the view port we can decide what image is appropriate. And that\u2019s good on something like this, like this is Wal-Mart grocery side on a small screen. The images are pretty much the same size as the view port. But as this page gets bigger, as the view port gets bigger, now it\u2019s about a third of the size of the view port. And as it gets bigger still, we realize that it\u2019s actually completely disconnected from the size of the view port. The view port is actually 15040 pixels wide, and those images are 254 pixels. There\u2019s no association between them.<\/p>\n<p>This challenge, this tug of war between <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> and what\u2019s called alternatively the speculative pre-loader or the look-ahead pre-parser, like there are different names that I\u2019ve heard from people who work on browsers for what this actually is but that thing that looks through the HTML and starts downloading assets before layout is done. This tug of war has been the reason why it took us five years to get to a different standard for <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. The way I like to think about it is it\u2019s like the two different types of people you might go on vacation with. Like that person who wants like everything lined up ahead of time, they want to know where they\u2019re going to be, where they need to go, they have their whole itinerary set. Versus the person who\u2019s like \u201cHey San Francisco I\u2019m here! Let\u2019s go figure out what\u2019s going on!\u201d Right? And on the left we\u2019ve got the look-ahead pre-parser. It wants to know what it should do right away. And <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> are like \u201cNo, no, no. Wait. Wait. Wait until the layout is done so that we know the exact image size in the page.\u201d<\/p>\n<p>This challenge is the reason why we can\u2019t solve <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> with like CSS or JavaScript, like why we needed a new standard. Or even like a magical new image format. People have talked for awhile about image formats like <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> where they download portions of an image and then you can stop halfway through the full image size when you\u2019ve got enough of the image to fill the space that you need. The problem is is that we don\u2019t know the size of the space! Right? When we\u2019re actually downloading the images. And we can\u2019t ignore this because the look-ahead pre-parser is a key to the faster web. The chrome team says that it sped up webpages by 20 percent when they implemented it. Firefox says 19 percent. Ilya Grigri did some research and found that 43 percent of the average webpages images are downloaded by that speculative loader. And that accounts for 50 percent of page weight. So 50 percent of your page weight is being downloaded by something that doesn\u2019t know the size of the images in the page. We can\u2019t ignore that problem.<\/p>\n<h2>Sizes<\/h2>\n<p>So this was something that we were stuck on for quite some time. And this brings us to the hero of our story which is sizes. Sizes is the attribute that people don\u2019t talk about but that\u2019s actually the one that will have the longest staying power out of all of these related to <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. Sizes is required any time we\u2019re using width descriptors. So any time we\u2019re using width instead of display density descriptors we have to have sizes there. And sizes basically has a series of media conditions, it\u2019s a subset of media queries, it does everything you would need it to do it just doesn\u2019t do thinks like print which doesn\u2019t make a lot of sense in this context. So it\u2019s got a media condition and then a length which could be a view port unit. So 100 percent of the view port unit or 33 of the view port unit. And then if there\u2019s no media condition then it\u2019s considered the default. So if none of the other ones match then it\u2019s going to be 254 pixels and that length can be absolute, it can be relative, or it can even be CSS calculated.<\/p>\n<p>So this particular rule actually is the rule that we might use for that Wal-Mart example. So here we are at 100 percent view port. And then once we reach a certain size we go to third of the view port and then as the screen gets bigger it\u2019s just 254 pixels. Just let it be. Now when we first started talking about sizes there was a lot of push back. And I think there\u2019s still push back because of the idea of separation of concerns, right? Sizes contains information about your design and it\u2019s in the markup and we would much rather have our markup just be the content, the design in the CSS, and behavior in JavaScript. And it\u2019s not like any of us who were working on this sort of stuff didn\u2019t realize that this was a problem, like we had many many conversations about it. But we just came to the conclusion that sizes was a necessary compromise between what <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> needed to do and speculative downloading behavior. And so while we\u2019d ideally not like to have that in markup, this solves that problem.<\/p>\n<h4>srcset and sizes<\/h4>\n<p>The really great thing about <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> and sizes is that they let browsers be smart. That list of sources isn\u2019t a declaration. It doesn\u2019t say you must download this image. It says \u201cHere\u2019s some images to choose from.\u201d You know better than us what\u2019s going on on that device. You may know the network speed, you may know if that users opt in to Googles fast browsing which I forgot the name of. Like there are a bunch of different factors that a browser could use to decide \u201cHey, even though this is a 2x display maybe we only want the 1x image.\u201d Or maybe this image is actually like size and the page happens to be two pixels wider than 320, we should just grab the 320 image and upscale it slightly. It\u2019ll still look good, nobody will know the difference. Right? Those are the sorts of things that we\u2019re hopeful that browsers will experiment with. They haven\u2019t done a lot of it yet but that\u2019s the idea behind providing them with <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> and sizes as a way to make those decisions.<\/p>\n<h2>&lt;picture&gt;<\/h2>\n<p>What about the picture element? I mean that\u2019s actually the name of the specification. I don\u2019t refer to the picture element or picture standard much anymore I usually say <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> standards because people got really fixated on picture. And picture is important but it\u2019s mainly important when it comes to art direction. Because what happens with the picture element is that you\u2019ve got a series of sources and you\u2019ve got media queries for these different sources and the first media query that matches tells the browser which image to use. And that\u2019s a declaration, that\u2019s a rule. You must use this image as opposed to what happens with <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> where you can pick from the different images.<\/p>\n<p>This makes the most sense in situations like what Shopify had where on widescreens they had sort of an image of one of their customers and then on small screens they cropped that image. So it\u2019s very important that on small screens that it actually grabs a different image. It\u2019s not just simply a resized version of the same image. And I use the picture element to accomplish that. There\u2019s actually another use of the picture element that\u2019s really exciting and that\u2019s to declare different types of images, basically different image formats that you want to supply to the browser. So we could use this type attribute to say \u201cHey, if this browser supports SVG, use this SVG version of this image.\u201d And if you use We Bp, use the We Bp version. You\u2019ll also note that in this example because we\u2019re not doing art direction we don\u2019t need the media queries. As a matter of fact we shouldn\u2019t use the media queries we should just provide the browser with different options and allow it to choose between these different options.<\/p>\n<p>This is really really exciting stuff. We haven\u2019t had this opportunity since the earliest days of the web. There are a bunch of different types of image formats that we could experiment with. Like <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> is something that I\u2019ve completely ignored. But does an incredibly good job with alpha transparencies. So this is a PNG that\u2019s 237k and the <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> version is only 51k, right? Much much better. Same this is true with the stile version. Right? The <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> version of the stile is 19k. We Bp is better it\u2019s 56k. PNG which is what we would normally use for this sort of thing is 325k. That\u2019s obscene right? That\u2019s much much too big. But we can\u2019t use <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> because it\u2019s not supported everywhere. But guess what it\u2019s actually supported in Safari. I didn\u2019t realize that but <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> works in Safari so we could use <a href=\"https:\/\/cloudinary.com\/blog\/the_great_jpeg_2000_debate_analyzing_the_pros_and_cons_to_widespread_adoption\">JPEG2000<\/a> right now for our Safari customers. And because of the picture element we could provide a WP fallback for people who are on the blank browser and we could provide a PNG fallback for whatever users don\u2019t support those two browsers.<\/p>\n<h2>Image breakpoints<\/h2>\n<p>This is an amazing opportunity that we haven\u2019t had in years. The ability to experiment with different image formats to try to find a better way of handling images on the web. And we can do it now because of the picture element. If that magical unicorn image format that solves all of our problems appears tomorrow the way that we can start using it is because of these <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> standards. Now when you start implementing <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> inside your organization, one of the big problems you\u2019re going to run into is related to image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a>. What I mean by image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> is how many image sources should we deliver? How many image sources make sense for a given image? If you\u2019re doing art direction it\u2019s really easy. Or it can be really easy. If you think back to that Nokia example, right, at some point the chrome got so small that it was unreadable and so because of that that\u2019s when they needed to create a different version of the image and we know that that\u2019s when we need to have different sizes, different versions.<\/p>\n<p>But if you\u2019re doing image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> for resolution switching it\u2019s much more difficult. Your instinct might be to approach it the same way you do <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive design<\/a> and responsive layouts. At least for us the way that we approach it is that we\u2019ll be working on a design, we\u2019ll be working on a portion of a design maybe a shopping cart and we\u2019ll start designing that shopping cart or that navigation and we start resizing our browser until it looks bad and then boom! That\u2019s when we need a breakpoint, right? We make decisions based on how those <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive designs<\/a> look and when the design breaks down at different screen sizes. But the problem with resolution switching is it\u2019s unclear when things are going to break down. How many image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> do we need between 2000 pixels and 200 pixels? Do we need two, do we need 10? And the images themselves aren\u2019t going to tell us a lot because if we simply size down an image, it\u2019s going to look exactly the same right? There\u2019s no point where the image starts looking bad.<\/p>\n<p>As a matter of fact it gets pretty problematic if we have an image that\u2019s 2000 pixels wide and it\u2019s 400 pixels in the page. If we instead down sampled that to 800 pixels it\u2019s 73k that\u2019s a big savings we should definitely do that. But you know what? 600 pixels wide is 42k and that\u2019s another 30 savings so we should definitely do that. But then you know what? 500 is actually 31k that\u2019s 11k, we should definitely deliver one that\u2019s 500. Well maybe at 450, right? Like you can just keep going and going, you\u2019ll just keep going until basically what you have is you have the actual image the size that it\u2019s in the page. Right? That\u2019s the only intrinsic information we know about that image. But we can\u2019t have every version at every size of an image, it just doesn\u2019t make sense.<\/p>\n<p>Scott Joe wrote about how when he was working on responsive, Scott Joe  worked on the Boston Globe site about how they decided to make differences of image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> based on sensible jumps and file size which, I was like well what\u2019s a sensible jump in file size and how do I make that sort of decision? Because images compress differently. Both of these are the exact same size, the one on the left is 151k, the one on the right is 13k. Right? So I started looking at this idea of applying a performance budget to <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. To be able to say \u201cHey, if we\u2019re going to in other areas of our design we\u2019re actually saying a new feature gets added to the page. We want to make sure that we know what the budget is for that new feature.\u201d Well flexible images is a new feature. So if we have a source image that\u2019s 500 by 333 and it\u2019s 58k, and in the page it gets shrunk down to 300 by 200, what would the size of that image be if we actually had sized it appropriately for the page?<\/p>\n<p>Turns out that it would have been 24k which means that the cost of using a flexible image on that page was 34k. So what if we decided that we only ever wanted to have a performance budget of 20k per image? Right? So we want to make sure that we deliver sources that are no more than 20k between the different sources so that nobody\u2019s ever downloading more than 20k than they actually need to display it in the page. And when you start looking at it that way, what you realize is that the images themselves tell you something about the <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a>. So this image would require eight <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> to have 20k between the different image sources. This one, three. This one, seven. And that logo only needs one. So I had this idea, it was sort of a crazy idea like the only thing that I had come up with that would actually be a way to do this in some sort of logical fashion as opposed to what I think a lot of people were doing which was just sort of arbitrarily deciding oh we need three image sizes because we\u2019ve got mobile, tablet, and desktop or something like that.<\/p>\n<p>And then a little bit ago I got this email from the people at Cloudinary and they\u2019re like \u201cHey. We\u2019ve built a tool that does this idea where you can adjust the small and the large and the small versions of it and you can select what you want as your performance budget and then it\u2019ll take that image and it will figure out how many different sources you need.\u201d And it\u2019ll also provide you with the markup and all the images that you can download and things like this. That was an amazing day, I gotta tell you. Here\u2019s this crazy idea I\u2019m not smart enough to actually figure out how to do this but I was so happy that somebody else did. But even with this I would say that most of the time image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> aren\u2019t a science yet, or at least they\u2019re not a practice science yet. The approach for performance budgets I think is probably the best one that I\u2019ve seen in terms of actually having some sort of logic for the way we pick them. But most organizations are just doing what I said which is like \u201cHey we\u2019ve got three layout <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a>, we\u2019re going to do three image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a>.\u201d If you cannot do something like performance budget based stuff for each individual image then at minimum pick some representative images and test how they compress and try to come up with a good number of images that makes sense for your design.<\/p>\n<p>Which brings me to another point. Humans shouldn\u2019t be doing this work at all. Adam Bradley had this quote he said \u201csave for the web should die.\u201d And he\u2019s absolutely right. There was a point in time in the past when we used to hand convert video right? But nobody does that now because there are way too many codets, way too many resolutions that you need to support different bit rates all of this sort of stuff, right? Now we use services that are designed to automatically adapt based on the speed of the person\u2019s browser, things of that nature. We shouldn\u2019t be doing this with images either. And I think that there are some things that are going to help us in that regard.<\/p>\n<h2>Client hints<\/h2>\n<p>The first is a new standard, it\u2019s not widely accepted or adopted yet but it\u2019s called client hints. So client hints is interesting. What it does is it takes HTTP headers so every time an image is requested, every time HTML or CCS is requested your browser sends some headers along and it adds some new headers. It adds DPR, the view port width, and the width of the image and the page. The two that I think matter are the DPR and the width. As I was showing earlier with the Wal-Mart grocery site, view port width often times has no relation to the size of the image in the page and so I think that there are some people who may find that useful but I can\u2019t think of a scenario where I would actually use that one. But the other two are really interesting because if we send that information in the header, then instead of having this markup, we can just do this. Right? We still need sizes but we can get rid of <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a>.<\/p>\n<p>In addition, this is not related to client hints but it\u2019s another header which is the accept header which tells the server what image formats the browser understands. And so if we combine these two things, if we combine client hints with the browser telling the user or the server what image formats it does, we can take this markup which right now is designed to declare WP and then JPEG XR and JPEG and different sources and a few different \u2026 It\u2019s doing some really complex things. I\u2019m very happy that we have this option because we didn\u2019t have this option in the past. But we can replace that with this. Right? It\u2019s a big win. So client hints are huge. In order to use them you have to add a meta tag to your page and you declare what hints you want. Unfortunately client hints are only supported in blink based browsers at the moment.<\/p>\n<p>And this brings a bit of a \u2026 Sorry. A chicken and an egg scenario when it comes to client hints because the browser makes a request to the server. The server doesn\u2019t know whether the browser supports client hints or not, but it has to decide whether to add that meta tag and it has to decide what markup to put in the page. Do we put that big long image stuff or can we just use the condensed version of it? But it doesn\u2019t know yet whether the browser supports that so it probably has to do both which right now means that client hints have this impediment both of the fact that it\u2019s not widely supported in browsers and also in order to support it you end up kind of duplicating work. This won\u2019t go on forever, hopefully the other browsers will start to implement it and there is some discussion going on about how to get away from sort of how the browser might actually indicate on that first request whether it supports client hints or not. So that we can then just present the correct markup based on whether the browser does.<\/p>\n<p>But right now the solution to this, the recommended solution is actually to use user agent detection to make these decisions. Which is really funny because one of the reasons why they started doing client hints was because they wanted to have an alternative to device detection databases which do everything based on user agent strings. So we\u2019re like \u201cWe\u2019re back!\u201d Kind of like we\u2019ve gone backwards and forwards at the same time. But client hints are something to keep your eye on because they really simplify the process of handling <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>.<\/p>\n<p>When you\u2019re looking at working on <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> inside your organization I highly recommend doing a <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> audit. We were working with an organization, large hotel chain they had I think it was 400,000 images in their site that had been hand cut and sized appropriately for the pages, and they were going to move to <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_guide_part_1_what_does_it_mean_for_an_image_to_be_responsive\">responsive design<\/a>. If they had three image sources that\u2019s 1.2 million images. If they decide to support retina displays, 2x displays that\u2019d be 2.4 million images. Huge number of images. It becomes really important to have a systematic view of images. So these are the sorts of questions that we end up asking. Where are the source files and what is the process for publishing them? Is there a big difference between the largest and smallest version of these images? Because if there isn\u2019t maybe we can get away with just a single source. Is it resolution switching or art detection? Can we use SVG? {lease, please, God, \u2018cause if we use SVG we don\u2019t have to worry about all this stuff. Are there representative images that we could use to provide sensible jumps or can we use some sort of way of doing that sort of automated way of detecting the number of image <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> that are needed? Do we need to support multiple image formats?<\/p>\n<p>And the end result of this for that site was we had a series of images and we were able to really bring them down to just five types of images. 90 percent of the images were property photography which at the time this was before <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> and sizes was available but ultimately what we would have used if it was available is we would\u2019ve used <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> and sizes on that. And that would have been the solution for the vast majority of the images. We had a few that were art directed where we had to make modifications to the CMS so that the CMS could support the designers uploading multiple versions of a particular image to support the different sizes that they would need across their design.<\/p>\n<h2>Responsive images in CMS<\/h2>\n<p>But then we had some other images that were like badges or awards that particular properties had won where the difference between the largest version of that image even with retina was not much different than the smallest version. So the decision was made for those images we just do the retina version, it wasn\u2019t that big a deal. It was just like little badges, awards. In general the big hope is automation related to <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. Again, we shouldn\u2019t be doing these on a manual basis we should be automating them. And there\u2019s a lot of work happening in this space. Picturefill is a polyfill that allows you to use <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> even in browsers that don\u2019t support the picture element in <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. We have at Drupal they worked on a picture module which has <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> support and it\u2019s actually part of Drupal 8 Core. WordPress, the <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> community group worked on a <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> plugin and that I believe Eric has also been put into the main core. Right? Yes. Okay. Thank you. I had a moment of doubt. But yeah, WordPress now does this by default and we see this over and over again that CMS\u2019s and E-Commerce systems and things like this are trying to figure out ways to incorporate them.<\/p>\n<p>There are also a bunch of imagery sizing services. I maintain a spreadsheet of all the different imagery sizing services that I\u2019m aware of. Some of them are software that you can install on your own systems, some of them are free services, some of them are paid services just sort of depends on what you\u2019re looking for. And they didn\u2019t ask me to do this but the Cloudinary stuff they are doing some really really good stuff in terms of <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a>. It doesn\u2019t hurt that they took my crazy idea and implemented it but from a <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> perspective you find \u2026 I\u2019m hopeful that other services will start doing the same sorts of things that Cloudinary\u2019s doing in terms of supporting <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> and <a href=\"http:\/\/www.responsivebreakpoints.com\/\">breakpoints<\/a> and making it so that you don\u2019t have to think about it, designers and developers on a daily basis. You just upload the largest possible image that you\u2019ve got and then you create your template and you put the markup in the templates and then you just let the machines do their business.<\/p>\n<h2>Clounclusion<\/h2>\n<p>All right. So I understand that <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> can seem daunting. I get that. I\u2019ve been there. I\u2019ve been there way too many times. Just remember that you\u2019re not alone. The really remarkable thing about the <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> community group is that it is a standard that was driven by designers and developers. It was driven by people who were working in the field as opposed to browser makers. And that\u2019s not to say that the browser makers don\u2019t create really really good stuff and that they didn\u2019t participate in this. I mean it\u2019s critical that the people who are involved in building browsers participated in the <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> group. But this is really a community driven effort. The people inside the <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> community group are here to help you if you\u2019re running into problems. Just this week I was answering questions from people on Twitter who were trying to figure out how to do things with <a href=\"https:\/\/cloudinary.com\/blog\/responsive_images_with_srcset_sizes_and_cloudinary\">srcset<\/a> and sizes. I\u2019m happy to help. Eric\u2019s part of the <a href=\"https:\/\/cloudinary.com\/documentation\/responsive_images\">responsive images<\/a> community group he would help. Matt Marquis. There\u2019s a bunch of folk, Yoav Weiss who works for Akamai, like a bunch of different people inside that group who will answer questions if you\u2019re running into problems.<\/p>\n<p>And in the long run we\u2019re going to build tools to make this climb easier. We just need to take the first steps. Vitaly, had talked about the fact that not many people are using these new standards yet. The time to start is now. We want to see how you use them. We want to learn from you, we want to learn how people are implementing them in the real world. And I\u2019d love to hear how you use them. So thank you very much.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"","protected":false},"author":41,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_cloudinary_featured_overwrite":false,"footnotes":""},"categories":[1],"tags":[68,167,251],"class_list":["post-21525","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-conference","tag-imagecon","tag-responsive-images"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v25.6 (Yoast SEO v26.9) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>ImageCon17: Delivering Responsive Images<\/title>\n<meta name=\"description\" content=\"Jason Grigsby&#039;s transcribed talk at ImageCon17, &quot;Delivering Responsive Images&quot;\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"ImageCon17: Delivering Responsive Images\" \/>\n<meta property=\"og:description\" content=\"Jason Grigsby&#039;s transcribed talk at ImageCon17, &quot;Delivering Responsive Images&quot;\" \/>\n<meta property=\"og:url\" content=\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\" \/>\n<meta property=\"og:site_name\" content=\"Cloudinary Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-05-23T21:54:03+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-05-18T16:56:09+00:00\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"NewsArticle\",\"@id\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images#article\",\"isPartOf\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\"},\"author\":{\"name\":\"\",\"@id\":\"\"},\"headline\":\"ImageCon17: Delivering Responsive Images\",\"datePublished\":\"2017-05-23T21:54:03+00:00\",\"dateModified\":\"2023-05-18T16:56:09+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\"},\"wordCount\":4,\"publisher\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/#organization\"},\"keywords\":[\"Conference\",\"ImageCon\",\"Responsive Images\"],\"inLanguage\":\"en-US\",\"copyrightYear\":\"2017\",\"copyrightHolder\":{\"@id\":\"https:\/\/cloudinary.com\/#organization\"}},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\",\"url\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\",\"name\":\"ImageCon17: Delivering Responsive Images\",\"isPartOf\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/#website\"},\"datePublished\":\"2017-05-23T21:54:03+00:00\",\"dateModified\":\"2023-05-18T16:56:09+00:00\",\"description\":\"Jason Grigsby's transcribed talk at ImageCon17, \\\"Delivering Responsive Images\\\"\",\"breadcrumb\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/cloudinary.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"ImageCon17: Delivering Responsive Images\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/cloudinary.com\/blog\/#website\",\"url\":\"https:\/\/cloudinary.com\/blog\/\",\"name\":\"Cloudinary Blog\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/cloudinary.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/cloudinary.com\/blog\/#organization\",\"name\":\"Cloudinary Blog\",\"url\":\"https:\/\/cloudinary.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/cloudinary.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/res.cloudinary.com\/cloudinary-marketing\/images\/f_auto,q_auto\/v1649718331\/Web_Assets\/blog\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877.png?_i=AA\",\"contentUrl\":\"https:\/\/res.cloudinary.com\/cloudinary-marketing\/images\/f_auto,q_auto\/v1649718331\/Web_Assets\/blog\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877.png?_i=AA\",\"width\":312,\"height\":60,\"caption\":\"Cloudinary Blog\"},\"image\":{\"@id\":\"https:\/\/cloudinary.com\/blog\/#\/schema\/logo\/image\/\"}},{\"@type\":\"Person\",\"@id\":\"\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"ImageCon17: Delivering Responsive Images","description":"Jason Grigsby's transcribed talk at ImageCon17, \"Delivering Responsive Images\"","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images","og_locale":"en_US","og_type":"article","og_title":"ImageCon17: Delivering Responsive Images","og_description":"Jason Grigsby's transcribed talk at ImageCon17, \"Delivering Responsive Images\"","og_url":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images","og_site_name":"Cloudinary Blog","article_published_time":"2017-05-23T21:54:03+00:00","article_modified_time":"2023-05-18T16:56:09+00:00","twitter_card":"summary_large_image","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"NewsArticle","@id":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images#article","isPartOf":{"@id":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images"},"author":{"name":"","@id":""},"headline":"ImageCon17: Delivering Responsive Images","datePublished":"2017-05-23T21:54:03+00:00","dateModified":"2023-05-18T16:56:09+00:00","mainEntityOfPage":{"@id":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images"},"wordCount":4,"publisher":{"@id":"https:\/\/cloudinary.com\/blog\/#organization"},"keywords":["Conference","ImageCon","Responsive Images"],"inLanguage":"en-US","copyrightYear":"2017","copyrightHolder":{"@id":"https:\/\/cloudinary.com\/#organization"}},{"@type":"WebPage","@id":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images","url":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images","name":"ImageCon17: Delivering Responsive Images","isPartOf":{"@id":"https:\/\/cloudinary.com\/blog\/#website"},"datePublished":"2017-05-23T21:54:03+00:00","dateModified":"2023-05-18T16:56:09+00:00","description":"Jason Grigsby's transcribed talk at ImageCon17, \"Delivering Responsive Images\"","breadcrumb":{"@id":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/cloudinary.com\/blog\/imagecon17_delivering_responsive_images#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/cloudinary.com\/blog\/"},{"@type":"ListItem","position":2,"name":"ImageCon17: Delivering Responsive Images"}]},{"@type":"WebSite","@id":"https:\/\/cloudinary.com\/blog\/#website","url":"https:\/\/cloudinary.com\/blog\/","name":"Cloudinary Blog","description":"","publisher":{"@id":"https:\/\/cloudinary.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/cloudinary.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/cloudinary.com\/blog\/#organization","name":"Cloudinary Blog","url":"https:\/\/cloudinary.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/cloudinary.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/res.cloudinary.com\/cloudinary-marketing\/images\/f_auto,q_auto\/v1649718331\/Web_Assets\/blog\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877.png?_i=AA","contentUrl":"https:\/\/res.cloudinary.com\/cloudinary-marketing\/images\/f_auto,q_auto\/v1649718331\/Web_Assets\/blog\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877\/cloudinary_logo_for_white_bg_1937437aa7_19374666c7_193742f877.png?_i=AA","width":312,"height":60,"caption":"Cloudinary Blog"},"image":{"@id":"https:\/\/cloudinary.com\/blog\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":""}]}},"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/posts\/21525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/users\/41"}],"replies":[{"embeddable":true,"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/comments?post=21525"}],"version-history":[{"count":7,"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/posts\/21525\/revisions"}],"predecessor-version":[{"id":29129,"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/posts\/21525\/revisions\/29129"}],"wp:attachment":[{"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/media?parent=21525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/categories?post=21525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cloudinary.com\/blog\/wp-json\/wp\/v2\/tags?post=21525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}