 Hello, and welcome to Ask Chrome. This is the show where you get to ask the Chrome team questions. My name is Sam Dutton, and I'm a developer advocate on the Chrome team. Hi, I'm Joao Weiss, also a developer advocate on the Chrome team. I've done a bunch of image-related work in my past, including being heavily involved in the Responsive Images community group. So I'm super happy to be here today to talk about images. Yeah, fantastic. We're honored to have Joao here today, because I know he's done a bunch of really good things with images. So thank you, Joao. Anyway, if you are watching on YouTube Premieres, you can add questions to the live chat. If you're watching this afterwards, then please just add questions to the comments, and we'll come back to you there. Thank you so much for all the questions on Twitter using the hashtag Ask Chrome. We've got a bunch of interesting topics to cover from them today. Again, I'm going to talk about image formats and SEO and compression and a bunch of new capabilities in the future. So yeah, a bunch of new things to get on to, but also a little surprise from Joao, I believe. Not really a surprise, but we'll talk a bit about the largest image on the web. Yeah, I guess that's not a surprise. But anyway, before we get on to image blight, we do want to talk about image formats because we've had a lot of questions about this, in particular, WebP, a question from Eugene Kopich, asking about WebP support in Safari. Now, Joao, if I know you don't work on Safari or WebKit, but any word on this? Nothing in particular. So iOS 10, one of the betas introduced WebP support, and then it got pulled out. And I know that the WebKit codebase has WebP support for various ports that are using it, but not for the Safari port of WebKit. I'm hopeful that with the recent development of support from Firefox and Edge, the WebKit team, the Safari team will reconsider and potentially add support in the future. Fantastic, yeah. It would be great to see that. I mean, one obvious point to make here is that, you know, it's really easy to code for WebP with fallbacks. We've actually had a question about this from Victor Lenichak. Just want to show some code on screen now that, in this example, shows how you can code for a transparent image using WebP but with a PNG fallback. Really simple stuff there. Also had questions about sort of successes and, you know, the future of WebP. A question here from Ryan Townsend. Now, I've kind of heard about, like, AVIF and other stuff, but I don't really know much about it. Joath, please, could you tell us more about the future formats? Sure. So, yes, AVIF is a still image format that's based on the AV1 video codec. And AV1 introduces a lot of new and exciting compression concepts that allow us to get significant compression gains. At the same time, when looking at images on the web, AV1 has trade-off when it comes to decoding speed and the decoding cost of AVIF images is a bit too high to be usable for images on the web. Okay. At the same time, maybe there are some things to learn from those compression concepts so that they can be applied to some future format. Yeah, I look forward to seeing what's happening there. I mean, it's really interesting, some of the stuff, you know, in still image technology that we're getting kind of off the back of, you know, research into video compression. So, I look forward to seeing where that goes. We've also had several questions about SEO. So, search engine optimization for images. A question from Thomas asking about SVG. Is SVG SEO friendly? And we've actually been to the search team here and asked them, and yes, is the answer. SEO is great for SVGs. SVGs will get indexed and appear on Google images just like any other image. Just bear in mind that, you know, text in the code in an SVG is not indexed. So, if you're using links and stuff in the text in the code for an SVG, that won't be indexed. Just bear in mind that inline images with SVG don't get indexed. So, just be aware of that when you're using SVGs. But also I wanted to mention, you know, that thinking about this from an accessibility perspective, how you can make images more accessible. Yeah, we also had a question from Thomas that related to the alt attribute and whether that's mandatory for SEO purposes. And I guess that beyond just SEO, it's mandatory for accessibility purposes because we really want all users to be able to understand our images. So, the alt attribute is fundamental for that. And also for SEO, Google search doesn't look into, doesn't try to decipher text inside of images. Gotcha. And yeah, the alt attribute is what it's facing. Yeah, it's still the way to go. It's indexing on, so that's definitely the way to go. Yeah, I mean, one thing that I've noticed is, you know, that if you're adding a text layer over a photographic image, it can really mess up your chances of getting good compression on that image. So, yeah, the short answer is keep your text and your images separate and you get better SEO and better accessibility. So, moving on to some other topics, actually, thinking about best practice. Going back to Victor's question, just want to show you a little extra markup that does some more stuff here. So, using a source set to enable the browser to choose different image sizes, depending on the viewport. And for bonus points, you can use the sizes attribute to actually specify the size of the image element that is in the display. So, two really useful attributes there. So, as you can see from the developer tools, Chrome is using the WebP and Safari is falling back to the JPEG. Now, we've also had a question from Eric Lawrence about WebP pointing out that, you know, some sites on Google don't use WebP. We had a check and, you know, most Google sites are using WebP. I mean, inevitably, some sites, you know, haven't prioritized adoption of WebP. I mean, I think that's just the way for a lot of organizations. So, next question was about animated GIFs. The question is, you know, should we stop using animated GIFs? And the answer is yes, yes. There are great tools like FFMpeg that make it really easy to encode from animated GIFs to a better format. And as you can see from the HTML markup here, it's really easy to use video for a much better alternative to an animated GIF. Just bear in mind that we have the muted attribute here, which means that, you know, autoplay is not blocked from platforms that otherwise would stop that. Yeah, and one more point related to animated GIFs. If you have many different animated GIFs on the same site, it might be better to convert them to an animated WebP rather than a video because videos are by default routed through the GPU and that can cause performance problems if you have too many of them on a single site. Right, yes. Thanks for reminding us. Yeah, so yeah, video or animated WebP. Okay, so since I managed to get Yo-F into the studio, I like, I get to ask a question, I believe, anyway. So my question really was about image dimensions. You know, back in the day, we were told don't put height and width on HTML elements. Since then I've heard about like intrinsic size and aspect ratio. You know, what's going on? Tell us the news. Sure, so adding width and height as part of markup was inherently something that was considered to go against the responsive web design. Yeah, that's right. You don't really know what the dimensions of the image will be because they can vary based on the viewport. At the same time that resulted in janky layout and reflows once the browser actually got the real image dimensions when it downloaded the image. So in order to resolve that, the Chrome team had a proposal for an intrinsic size attribute which would give the browser ahead of time the intrinsic dimension of the image or its aspect ratio and that will enable the browser to get layout right the first time around. So to look out the height based on knowing the width. But feedback we got from the Mozilla folks was that they're not super excited about adding yet another attribute on image when we already have the width and height attributes. So if we will slightly change the way that people do responsive design and have them also define like both the width and the height as part of CSS, that would mean that we can use the width and height attributes in order for the browser to know what the intrinsic dimensions are or what the aspect ratio is. So the browser can use that in order to determine the initial intrinsic dimensions which are currently fixed but will be based on those attributes up until the point where the browser actually downloads the image and knows what the final dimensions are. So I can use that to get the aspect ratio without having to first download the image. That's cool, okay. And Yoav, while you're here, I also wanted to ask about lazy loading. Can you tell us where that's going? So people have been using JavaScript in order to lazy load images for the longest while and now finally starting from Chrome 76 that exists in native and all you have to do is just add the loading attribute with a lazy value and the browser will do the right thing and only load the image when the user is very likely to actually see it. Similar to JavaScript based lazy loading, you don't wanna do that for images that are very likely to already be in the viewport but mostly focused on images that are not likely to be in the initial viewport but the user will scroll to them eventually in some cases. Yeah, that's great to see. And yeah, one last thing we did promise you earlier to find out about the biggest image on the web. What's the deal, Yoav? Sure, so we sent out this tweet related to images and asked Chrome hashtag and Adios Money, our colleague, asked, what's the best image on the web? And folks in the community obviously immediately said the biggest one and Paul Kovano and Rick Viskomi digged up that data from the HTTP archive and came up with a bunch of very large images. So 59 meg JPEG, which turned out to be mostly background noise as well as a huge image. Fantastic, yeah, yeah. And Eric Portis from... We sent a few hero images like this. Yeah, Eric Portis from Cloudinary managed to downsize that a bit and compress it down to 60K, which is way more reasonable. Yeah. And otherwise there was a 30 meg arrow SVG, which was mostly a clip path based image data, which can be, you know, probably 10 bit downsize into 10K. Just like an arrow, yeah, yeah, yeah. Oh, that's amazing. Yeah, it's always great to hear. You know, that's like, you know, the possibilities on the web with images. I mean, you can get from like 60 meg to 60K. That's actually really good news. So thank you so much, Yoav, for being with us today. I really appreciate that. And thank you, everyone, for all your questions. You can post more questions using the Ask Chrome hashtag on Twitter, or you can just post comments on this video on YouTube. So thanks so much, and thanks again, Yoav. Thank you. Goodbye.