Talk Summary
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've been clamoring for—a solution for responsive images baked into browsers. Now the hard work begins.
Jason Grigsby is co-founder of Cloud Four, a small web agency in lovely, Portland, Oregon. He co-authored Head First Mobile Web for O'Reilly, was part of the team that worked on the Obama '08 iPhone app, founded Mobile Portland along with the first open device lab; and was a signatory to the Future Friendly Web manifesto.
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.
Responsive images have finally landed
After five years many specifications, some inflamed Twitter battles and other conversations, responsive images have finally landed and there's a sound. Which is really exciting right? People have been climbing for this for quite some time and we've reached a point where they're available in modern browsers. So people were excited, they wanted to go use them it's something that designers and developers have had as a point of frustration for a long time.
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't 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.
Yeah! 51 years!
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 responsive images. And then all of a sudden they start looking at it and they're like "What hath we wrought." Right? Like look at all this mark up this is a huge huge Road Runner that we've just caught. And you see this in the comments on blog posts where people talk about "This is way too complex. Can you imagine doing this for 300 images?" Or "There's so many things wrong with these new responsive images systems. I don't have the time to enumerate the numbers of ways in which this is wrong." 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't use CSS gradients on the web.
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's complex because any time there's 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've 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't 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.
The next year that wasn't 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'm 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's a lot of visual gradation or differentiation from line to line whether it's vertical or horizontal makes a big difference.
Use Cases
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 responsive images that we've got available to us. In order to do that we have to talk first about some use cases. So the responsive images community group which worked on this created a series of use cases related to responsive images but I really just narrow it down to two.
Resolution switching
The two use cases that I think matter the most are resolution switching, and this is the idea that you've 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.
Art direction
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's talking about the success of the auto bailout. So if we're 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's speaking. We'd be much better off if we actually cropped closer to the speaker so that you could actually make out the details. So that's one form of art direction. But it doesn't have to be cropping.
Not simply cropping
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 responsive design work.
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't see the chrome. You couldn't see the details, and so they ended up creating a portrait version that was cropped. So that's another version of art direction.
Art direction: Images with text
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've 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't a responsive design 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's kind of insane what they do. And because of that they can't 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't be able to read the text so they create an alternate version of the image. And we know that you couldn't 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't read it.
<img> is always required
So despite the fact that they do it differently on their homepage actually on the actual catalog page they're 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're going to use which responsive image standard. So first we're 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's a box in to which all of these new responsive image standards go into. Whether it's picture or source set or sizes, whatever those rules are that are applied, they're 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're in this case as the picture element is being applied, the media queries in the picture element are being applied.
Now the first question I ask is if you've got an image element do you need anything else? And if you have a fixed width design, you don't, right? The image element is sufficient. Or in some cases even in a responsive design this is Rainbow Nursery, this really great and beautiful UK nursery. They've got a great design and in the responsive design 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.
srcset
Where things get different is when we start looking at high density displays, right? And this is where srcset comes in comes in, the ability to define multiple sources. So srcset 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 'x' descriptors or display density descriptors and so in this case we've got two images. One that's a 1x image, one that's 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's actually 256k at 1x and 508k at 2x. So if that's all we provide that's going to be far too large for somebody on a mobile device. We need more source files. Thankfully srcset 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.
Now what's important about this is that it's different than the way that usually happens in CSS where we're 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 responsive images really challenging.
How will the browser pick the best source?
So if we look at sort of a typical web page and the way it loads one of the things you'll 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's receiving data about the images more information's 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's 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's the big problem.
If we go back to this example, how do we know which of these sources we should grab if we don't yet know what the size if of the image and the page when it's downloading? A lot of sort of simplistic versions of responsive images 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's 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's about a third of the size of the view port. And as it gets bigger still, we realize that it's 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's no association between them.
This challenge, this tug of war between responsive images and what's called alternatively the speculative pre-loader or the look-ahead pre-parser, like there are different names that I've 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 responsive images. The way I like to think about it is it's 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're going to be, where they need to go, they have their whole itinerary set. Versus the person who's like "Hey San Francisco I'm here! Let's go figure out what's going on!" Right? And on the left we've got the look-ahead pre-parser. It wants to know what it should do right away. And responsive images are like "No, no, no. Wait. Wait. Wait until the layout is done so that we know the exact image size in the page."
This challenge is the reason why we can't solve responsive images 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 JPEG2000 where they download portions of an image and then you can stop halfway through the full image size when you've got enough of the image to fill the space that you need. The problem is is that we don't know the size of the space! Right? When we're actually downloading the images. And we can't 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't know the size of the images in the page. We can't ignore that problem.
Sizes
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't talk about but that's actually the one that will have the longest staying power out of all of these related to responsive images. Sizes is required any time we're using width descriptors. So any time we're using width instead of display density descriptors we have to have sizes there. And sizes basically has a series of media conditions, it's a subset of media queries, it does everything you would need it to do it just doesn't do thinks like print which doesn't make a lot of sense in this context. So it's 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's no media condition then it's considered the default. So if none of the other ones match then it's going to be 254 pixels and that length can be absolute, it can be relative, or it can even be CSS calculated.
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's 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's still push back because of the idea of separation of concerns, right? Sizes contains information about your design and it's 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's not like any of us who were working on this sort of stuff didn't 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 responsive images needed to do and speculative downloading behavior. And so while we'd ideally not like to have that in markup, this solves that problem.
srcset and sizes
The really great thing about srcset and sizes is that they let browsers be smart. That list of sources isn't a declaration. It doesn't say you must download this image. It says "Here's some images to choose from." You know better than us what's 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 "Hey, even though this is a 2x display maybe we only want the 1x image." 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'll still look good, nobody will know the difference. Right? Those are the sorts of things that we're hopeful that browsers will experiment with. They haven't done a lot of it yet but that's the idea behind providing them with srcset and sizes as a way to make those decisions.
<picture>
What about the picture element? I mean that's actually the name of the specification. I don't refer to the picture element or picture standard much anymore I usually say responsive images standards because people got really fixated on picture. And picture is important but it's mainly important when it comes to art direction. Because what happens with the picture element is that you've got a series of sources and you've got media queries for these different sources and the first media query that matches tells the browser which image to use. And that's a declaration, that's a rule. You must use this image as opposed to what happens with srcset where you can pick from the different images.
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's very important that on small screens that it actually grabs a different image. It's not just simply a resized version of the same image. And I use the picture element to accomplish that. There's actually another use of the picture element that's really exciting and that's 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 "Hey, if this browser supports SVG, use this SVG version of this image." And if you use We Bp, use the We Bp version. You'll also note that in this example because we're not doing art direction we don't need the media queries. As a matter of fact we shouldn't use the media queries we should just provide the browser with different options and allow it to choose between these different options.
This is really really exciting stuff. We haven't 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 JPEG2000 is something that I've completely ignored. But does an incredibly good job with alpha transparencies. So this is a PNG that's 237k and the JPEG2000 version is only 51k, right? Much much better. Same this is true with the stile version. Right? The JPEG2000 version of the stile is 19k. We Bp is better it's 56k. PNG which is what we would normally use for this sort of thing is 325k. That's obscene right? That's much much too big. But we can't use JPEG2000 because it's not supported everywhere. But guess what it's actually supported in Safari. I didn't realize that but JPEG2000 works in Safari so we could use JPEG2000 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't support those two browsers.
Image breakpoints
This is an amazing opportunity that we haven't 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 responsive images standards. Now when you start implementing responsive images inside your organization, one of the big problems you're going to run into is related to image breakpoints. What I mean by image breakpoints is how many image sources should we deliver? How many image sources make sense for a given image? If you're doing art direction it's 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's when they needed to create a different version of the image and we know that that's when we need to have different sizes, different versions.
But if you're doing image breakpoints for resolution switching it's much more difficult. Your instinct might be to approach it the same way you do responsive design and responsive layouts. At least for us the way that we approach it is that we'll be working on a design, we'll be working on a portion of a design maybe a shopping cart and we'll start designing that shopping cart or that navigation and we start resizing our browser until it looks bad and then boom! That's when we need a breakpoint, right? We make decisions based on how those responsive designs look and when the design breaks down at different screen sizes. But the problem with resolution switching is it's unclear when things are going to break down. How many image breakpoints do we need between 2000 pixels and 200 pixels? Do we need two, do we need 10? And the images themselves aren't going to tell us a lot because if we simply size down an image, it's going to look exactly the same right? There's no point where the image starts looking bad.
As a matter of fact it gets pretty problematic if we have an image that's 2000 pixels wide and it's 400 pixels in the page. If we instead down sampled that to 800 pixels it's 73k that's a big savings we should definitely do that. But you know what? 600 pixels wide is 42k and that's another 30 savings so we should definitely do that. But then you know what? 500 is actually 31k that's 11k, we should definitely deliver one that's 500. Well maybe at 450, right? Like you can just keep going and going, you'll just keep going until basically what you have is you have the actual image the size that it's in the page. Right? That's the only intrinsic information we know about that image. But we can't have every version at every size of an image, it just doesn't make sense.
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 breakpoints based on sensible jumps and file size which, I was like well what's 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 responsive images. To be able to say "Hey, if we're going to in other areas of our design we're 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." Well flexible images is a new feature. So if we have a source image that's 500 by 333 and it's 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?
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's 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 breakpoints. So this image would require eight breakpoints 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've got mobile, tablet, and desktop or something like that.
And then a little bit ago I got this email from the people at Cloudinary and they're like "Hey. We've 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'll take that image and it will figure out how many different sources you need." And it'll 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's this crazy idea I'm 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 breakpoints aren't a science yet, or at least they're not a practice science yet. The approach for performance budgets I think is probably the best one that I've 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 "Hey we've got three layout breakpoints, we're going to do three image breakpoints." 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.
Which brings me to another point. Humans shouldn't be doing this work at all. Adam Bradley had this quote he said "save for the web should die." And he's 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's browser, things of that nature. We shouldn't be doing this with images either. And I think that there are some things that are going to help us in that regard.
Client hints
The first is a new standard, it's not widely accepted or adopted yet but it's 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't 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 srcset.
In addition, this is not related to client hints but it's 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 ... It's doing some really complex things. I'm very happy that we have this option because we didn't have this option in the past. But we can replace that with this. Right? It's 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.
And this brings a bit of a ... 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't 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't 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's not widely supported in browsers and also in order to support it you end up kind of duplicating work. This won't 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.
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're like "We're back!" Kind of like we've 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 responsive images.
When you're looking at working on responsive images inside your organization I highly recommend doing a responsive images 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 responsive design. If they had three image sources that's 1.2 million images. If they decide to support retina displays, 2x displays that'd 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't maybe we can get away with just a single source. Is it resolution switching or art detection? Can we use SVG? {lease, please, God, 'cause if we use SVG we don't 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 breakpoints that are needed? Do we need to support multiple image formats?
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 srcset and sizes was available but ultimately what we would have used if it was available is we would've used srcset 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.
Responsive images in CMS
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't that big a deal. It was just like little badges, awards. In general the big hope is automation related to responsive images. Again, we shouldn't be doing these on a manual basis we should be automating them. And there's a lot of work happening in this space. Picturefill is a polyfill that allows you to use responsive images even in browsers that don't support the picture element in responsive images. We have at Drupal they worked on a picture module which has responsive images support and it's actually part of Drupal 8 Core. WordPress, the responsive images community group worked on a responsive images 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's and E-Commerce systems and things like this are trying to figure out ways to incorporate them.
There are also a bunch of imagery sizing services. I maintain a spreadsheet of all the different imagery sizing services that I'm 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're looking for. And they didn't ask me to do this but the Cloudinary stuff they are doing some really really good stuff in terms of responsive images. It doesn't hurt that they took my crazy idea and implemented it but from a responsive images perspective you find ... I'm hopeful that other services will start doing the same sorts of things that Cloudinary's doing in terms of supporting responsive images and breakpoints and making it so that you don't have to think about it, designers and developers on a daily basis. You just upload the largest possible image that you've 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.
Clounclusion
All right. So I understand that responsive images can seem daunting. I get that. I've been there. I've been there way too many times. Just remember that you're not alone. The really remarkable thing about the responsive images 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's not to say that the browser makers don't create really really good stuff and that they didn't participate in this. I mean it's critical that the people who are involved in building browsers participated in the responsive images group. But this is really a community driven effort. The people inside the responsive images community group are here to help you if you're 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 srcset and sizes. I'm happy to help. Eric's part of the responsive images community group he would help. Matt Marquis. There's 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're running into problems.
And in the long run we're 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'd love to hear how you use them. So thank you very much.
