Thank you very much for that introduction and good morning or good afternoon to you all, wherever you may be. And thank you very much for joining us on this panel today. So with me I have Cassidy, Hussein and Eric who are going to be joining this discussion on web performance and Core Web Vitals with me and I'll let them to introduce themselves to you. So let's start with Cassidy. Hi everybody. My name is Cassidy Williams and I'm a principal developer experience engineer at Netlify and I like making memes. I think that's a good enough summary. Am I right? Yeah. Thank you. Hussein. Hi everyone. My name is Hussein Jirdeh and I work on the Google Chrome team focusing on improving open source frameworks and tooling. Thank you. And last but not least, Eric. Hi, my name is Eric Portis. I get to work with Tomas at Cloudinary where I'm the web platform advocate. I'm trying to bring a little bit of Cloudinary's experience in media and the web to browsers and standards discussions and also try to make sure that Cloudinary is making use of everything the web platform has to offer. All right. Thank you, Eric. And as Eric was saying, my name is Tomas. I work at Cloudinary as a developer experience engineer and I'm happy to be here as well. So yay. Okay. So yeah, exciting. So I sent out a tweet just before we get to web performance. I sent out a tweet and I said, there's going to be some jokes. So I'm going to start with one. It's going to be terrible, but I try to lighten up the mood. So it's a typical classic knock knock joke, right? So it goes like knock knock, an async function. Who's there? Just, yeah. Just, just to get the mood. Thank you. All right. So on a more serious note. So today we're here to talk about web performance and Core Web Vitals. And I guess my first question to you all is, you know, web performance is important, but can we talk about, you know, what, why is web performance important in the first place? Why developers should, you know, really care about this? And I'll go with Hussain for this first question. For sure. Yeah. Definitely a good first question. Web performance is core, is a factor of accessibility. When anyone takes the time to ensure that their site meets a certain performance bar, they're making sure that their site is more accessible to more people. And as every year passes, more people are using the web in all parts of the world with all kinds of limitations, like a poor network connection or weaker device. If you take a look at resources like HTTP archive to try and analyze how web performance is changing over time, you'll find out that although device and connection capabilities are improving worldwide, the web as a whole is getting slower at a much faster rate. So performance in itself isn't just a feature, it's a necessary measure to make sure a webpage can be used by anyone at any time. Okay. Anyone else would like to add something to that? Actually that I love it and I agree. That's the most succinct way I've ever heard it said. Because it really is true. There's so many users of the web that don't have fast internet connections, don't have the ability to just like load all the JavaScript in the world. And so being able to have a performance site that works and loads quickly and works quickly is so important just for people to be able to use the things that you make. Okay. Thank you. So yeah, we established that web performance is important. Now you also mentioned a lot of websites out there that a lot of people using the web, but we can't deny the fact that the web is also visual, right? So every website that we visit is full of images, cat videos, more cat videos, videos about Cassidy doing her stuff. So there's lots of visual content out there. So the question is, what can developers do to make sure that their sites still perform well, even if they have lots of images and media assets on the page? So what options are available for them? Eric? Yeah. So when I think about the visual web and performance, I worked with Tomas last year on the HTTP archive or HTTP almanac chapter on media. And sort of the top line finding there was that two thirds of the media and website is media bytes. So you have all the bytes of the media and website. 67% of them are for images and videos. And on the one hand, unlike JavaScript or CSS, these are kind of cheap bytes. They don't block rendering. And while decoding images does take CPU time, it's not going to block the main thread for hundreds or thousands of milliseconds like JavaScript. But on the other hand, first, they can sort of have a big memory impact, which is important for battery life on certain devices. But maybe more importantly, they're often very important content. You mentioned the web becoming increasingly visual. We have this concept of a hero image or a hero element on a page, which is like the product shot or headline image of a news story, maybe the video on a YouTube page, like the thing that someone came to the website to see. And it doesn't matter how many non-blocking paints around that image are happening. The faster you show the product that someone's thinking of maybe buying, the better the user experience is going to be, the better your business metrics are going to be. So I think the first and most important thing that people can do to improve media performance is actually to look at the website and figure out what's important and use some of the newer tools that the web platform is providing you, like preload and things, to make sure that that stuff is happening first and loading first. And then take everything else and make sure that it's getting out of the way. The best optimization you can do is to not load something at all. So things like for images and videos, specifically lazy loading things instead of preloading things that are going to be further down on the page or that are less important, even above the fault, is probably the most important and highest impact optimization thing you can do. Then, of course, optimize your resources. It goes without saying, but it's a really complex, multidimensional problem. You've got to pick the right format for the content. If you have a logo that can be an SVG, use that. If you have a big photograph, don't send it as a GIF. Figuring out what format to use for different things is crucial. Dialing in quality settings and strike a good balance between quality and speed. And I could spend 20 minutes talking about this, but making your media responsive, which is a whole world unto itself, both to different browsers that support different formats and obviously different device resolutions and sizes. The good news is while figuring out what's important about a page, that first thing is a really human task that takes work, resource optimization and responsive delivery can in large part be automated. So maybe let's say the second most important thing you can do for media performance is to make sure that no one's actually doing it manually every time they check an image or a video onto a site. But I would say the most important thing you can do is to just track performance, media performance and performance generally, and try to build a culture of performance within your organization that really cares. I can give somebody a million tips and tricks about how to optimize their media. None of that really matters if the problems in the longer term end up being invisible or if there are organizational barriers preventing the people who do care from actually acting and solving these problems. That's the real hard work of media performance and just performance generally. Okay. Thank you. So it seems as developers have, they have a lot of work to do to create a site that is performance. So do you have any recommendations to sort of tools or things that they can use in order to measure and monitor the performance of a given site? So I don't know, maybe Cassidy, do you have any sort of tools at your disposal that you would recommend to developers to use? There's this really great quote from Phil Hawksworth on my team where he said, to make my site fast, I simply didn't add things that made it slow. And so that's something that it's something to consider because oftentimes the best tool that you can add is nothing. It's just like don't add as much bloat as you can. But besides that, in terms of tools that you can use and things that you can do, a lot of developers are going more and more towards the Jamstack way of building in terms of pre-building as much of your site as you can and pulling in data as needed. And in doing a lot of that, it's just a lot less code running when a page is loaded. It's just something that has already been run on our end. So that way it's easier for users of your sites to be able to use it. Which is a silly sentence, users use it. But anyway, between those things and then just all the different measurement tools, whether you use Lighthouse, which I'm sure Hussain has plenty to say about those kinds of things. And also just kind of looking at your bundle sizes, utilizing your logs in a really good way and really just see where are things the slowest, where are things that you can improve here and there. You can kind of keep it simple while also just kind of, again, try not to add too much complexity. Try to keep things as small as you can. Okay. Hussain, did you want to say something about Lighthouse? Yeah, no, like Cassidy I think hit the nail on the head. There are a lot of tools out there. But even before using these tools, essentially just making sure that you're not shipping anything that you don't need. These tools will help. Lighthouse is one of them. It's an open source audit tool that was started by the Chrome team, but it's open source and it measures performance among other page factors. And it gives a score on how well they're performing as well as what exactly you can do to improve. Now Lighthouse provides scores as sort of a lab-based environment. There are other tools out there that do very similar things like Chrome User Experience Report, but they give you performance scores on real users on your site. So both Lighthouse, both Chrome User Experience Report, and there's even other tools within Google, outside of Google, that can really help developers pinpoint exactly what issues are happening. And they're just a good forcing function to make sure that your thresholds are met and your bars are met. But again, if you don't even need to use the tools in the first place, you're doing something pretty well. Okay. Thank you. Yeah, I do like Lighthouse myself as well and I use it quite a lot. I also like how it tells you stuff about the visuals on your website as well. So it actually tells you whether your image is in the next gen format. And as far as I know, because it's open source, you can also sort of create your own tests and add that to Lighthouse, which is very, very useful as well. Okay. So quick joke time. Do you know how you help JavaScript errors? You console them. Okay. I'll probably stop my camera in a minute. So yeah, I should. Okay. All right. So moving on. The other part of this discussion, we talked about web performance, but let's also talk about Core Web Vitals. So where did they come from? How are they going to help developers? Are they helping developers? Are they helping the end users? You know, what can people do with Core Web Vitals? Let's start with Hussain. Yeah. So Web Vitals is a Google initiative that provides a set of metrics that lets anyone measure user experience on their site and identify important opportunities to improve. Core Vitals are a subset of the entire list of Web Vitals and are currently three useful metrics. Largest Contentful Paint, which is an indicator of speed that measures how long it has taken for the largest element on the page to fully load. Cumulative Layout Shift, which measures visual stability by calculating the number of layout shifts that occur during a session. And First Input Delay, which provides an indicator of responsiveness and interactivity by measuring how long it takes a page to respond after the first user interaction. Now these set of metrics can and will most likely evolve over time, but they're important for developers because they provide a simple way to quantify the most pressing issues on a site for a developer to focus on. They're like the tools that I mentioned that Cassidy was talking about, Lighthouse, Chrome User Experience Report, they're all beginning to embed these metrics within these tools. And both measuring them in a lab environment and in a real world sort of environment. You also want to make sure that the thresholds that these metrics are set are being met and they help signify what a good loading experience is. Because it's hard usually to say what makes a good performance site. These metrics are a way to sort of follow that direction. Okay. Thank you. Anyone else would like to add something to that? What's cool to see is that more and more frameworks and libraries are taking those kinds of core web vitals into account. Like I know, for example, the Next.js team, they worked with Google to get some actual measurement functionality in the framework itself. So that way you can measure that on your own. And it's really cool to see that going more and more towards being common in the industry. Because if more and more people are actually using core web vitals and other performance metrics, it makes for a more performant web. And like Hussain was saying before, a more accessible web. And so I don't have a lot to add in terms of like these are what they are. But I am excited to see more and more people using them. Okay. Thank you. Actually, just a follow-up question for you, Hussain. So you mentioned these three metrics. Could you tell us in one or two sentences what they do, what they intend to measure? Yeah. So the idea behind sort of having three metrics is to measure essentially all the aspects or the most important aspects of page experience. So the first one, large accounts of paint indicates speed. How fast does it take for something to render on a page? Cumulative layout shift measures actual shifts happening. I'm sure many of us here have experienced sites where we try to click on a button and then an ad banner pops up and it's just frustrating. So how do you quantify that? Cumulative layout shift actually provides a way to do that. And first input delay provides an extra factor of kind of measuring how long does it take for a site to respond. Maybe there's content. Maybe the content loads within half a second. But some of us, I'm sure, have experienced trying to click on a button, nothing happening in two or three seconds because the JavaScript thread still needs to settle. So the idea behind having three different metrics is to measure all the most important aspects of a page in terms of performance. And again, this is going to evolve. So these are sort of initially what Chrome thought and Google thought are essential. But we're working with other browser vendors, we're working with communities to try and figure out what else can we do. Should we add more metrics? Should we change them? Should we change how they work? This is going to be an ongoing basis. Okay, thank you for that. So I guess just to make some correlation here. So you mentioned LCP, Largest Contentful Paint, and then Eric mentioned a hero image. So I think there's some correlation in between these two things, right? So if you have a hero image being the largest content above the fold when your page loads, you want to make sure that you optimize that to get a good LCP score. I think that's a valid statement, right? So it's important to... Okay, cool. So developers use a lot of JavaScript frameworks, a lot of different JavaScript frameworks. There's a myriad amount of frameworks out there today. So what are these frameworks doing in terms of allowing developers to create performance websites? So are you aware of any sort of tools and techniques that these frameworks provide you to create performance sites? Cassidy, do you have any sort of samples for us or examples? I kind of touched on it earlier when I mentioned how Next.js added those kind of performance metrics. But again, it's one of those things where the developer community has been kind of going all in on this. Like, I can't tell you how many Gatsby plugins have been made to just measure performance and to optimize images and stuff. And you're seeing this across the board where people are making their own individual plugins. I mean, even at Nullify, there's a build plugin that'll automatically run Lighthouse on your build, no matter what framework that you use. There's so many community initiatives on that, that it's cool to see. And so it's hard to just pinpoint one example when there's so many. Okay. Anyone else has any thoughts on that? Yeah, no. I definitely want to add on to that. I think that was perfectly said. I'm glad, Cassidy, that you mentioned sort of Next.js as one example. The work that I do in Chrome is pretty much focused on trying to figure out ways for these frameworks and tools to perform better. I think in the past year, two years, three years, we've realized that although we can tell developers that there are many ways to improve performance in our site, and although that's useful, the ideal state would be the tools that developers use, like these frameworks, are already ensuring that their site is performing so that the developer doesn't have to do any work. The Next.js is a good example because we in Chrome, a small team within Chrome, have started working closely with the Next.js team and the React team to try to figure out ways how can we bake in better defaults. The Web Vitals, Core Vitals, Analytics dashboard in Next.js is a great example that Cassidy mentioned. That's only one of the things we helped with. We're also talking with the Angular team. We're working with the Nuxt team and the Vue team. Our goal is to just keep expanding that effort and to make sure that all these frameworks are essentially performing at a certain bar and have the right tools, have the right plugins, have the right baked-in features so that developers don't have to worry about them. They can just measure these Core Vitals, but they don't have to actually worry about doing all the work themselves. Okay, awesome. I think just to add something on top, if I may, I think most of these frameworks, I think all of these frameworks, React, Angular, et cetera, they all provide you with features like component-level lazy loading. You can just leverage that and utilize it in your code, and your app is going to perform better. Also, latest releases of Chrome support image lazy loading natively as well, so you can also utilize it. There are lots of tools at your disposal. Okay, so yes. Really quick, what kind of image saves the day, a hero image? Okay, that was a good one, and unplanned for. Yes, okay, go on, sorry. No, that's fine. I have another one. Why are developers unhappy at their job? Because they want a raise? Nice. Excellent. Okay, right, so how much time do we have left, roughly? Let's see here. Five minutes, 10 minutes? Five, 10 minutes, okay. So, I have a question, 10 minutes, okay. So, I have a question to Eric. So, we talked about visual graph, we talked about largest content for paint, we talked about Lighthouse. What if I see something in Lighthouse that says use a next-gen image format? So, what does that mean? Could you tell us what is a next-gen image format and how is that related to web performance? Yeah, we're at a really interesting time as far as images on the web. It seems like forever we've had a very stable collection of universally supported formats, like PNG, GIF, SVG, and the decision about what format to deploy and what scenario was at least, if not always simple, knowable, right? But now we're in this crazy new time where a few years ago WebP started making inroads onto the scene and recently now enjoys universal support. I think Safari shipped support this past year, and so now that's a format you can use anywhere. And which is great, except for in old browsers, and now there's even more confusing things because you have AVIF, which just was supported in Chrome, I think, last fall. And hopefully this year it's behind the flag right now in Canary. JPEG XL, which is another next-generation image format. And JPEG is a very amazing format. It is also very old. It's almost as old as me. I think it was first version shipped in 1980-something. So that's ancient history, right? So obviously the state-of-the-art in image compression has advanced a lot since then, and these new formats all try to bring those new advances to the web in a way that's compatible with the web's open nature and patent story and all that. And they're really cool. You can play with them, and probably the easiest way to do it is an excellent web app called Squoosh, Squoosh.app, and you can just fiddle with encoding settings and just see how small these images can get in these new formats. And of course you want to bring those savings to users. I think the jury's still a little bit out on definitive, this format is 20% bigger than this, and it all depends. But in general, with that disclaimer, WebP is maybe a quarter better than JPEG for general sorts of images, and AVIF and JPEG XL are even twice that as far as gains. So these are gains that you want to bring to your users. Doing so is complicated when users don't all have support, because the last thing you want to ship to somebody is a broken image. And there's a couple ways that you can send different resources to different users. One is to use the picture element, which has various source elements that have a type attribute, and the browser looks at that type attribute and says, oh, here's an AVIF, I can actually load that, I'm going to load that. Oh, I can't load that, I'm going to go to the next one. Oh, there's the JPEG, I'll just load that instead. So that's a markup-based solution. You can also do it server-side. For ages on the web, we've had the accept header, which the browser advertises, hey, server, here's what I want, here's what I actually can load. And the server says, oh, okay, here's what I can give you. So I'll give you the best format that you can actually use. So that all happens at the HTTP header level, and that stuff is easier to automate, maybe, than the markup-based solutions. But yeah, so doing the work to figure out how to add, making your life as a developer maybe a little bit more complex, but doing that for your end users is pretty important. Okay. So to sum it up, you can save kilobytes, and you can potentially allow websites to load faster as well, because the image size is going to be smaller, right? So that sums it up. Also, one thing to add, right, so we did mention the JAMstack for multiple reasons. You can use CDN providers for this automated next-gen image delivery, but also some of these static site generators that are used within the JAMstack have image components that can do that for you as well. So you have a lot of options in that space. So last question, and this will go to you, Hussein, if you don't mind. So this is back to Lighthouse. You do have the LCP and the CLS metrics, the largest contentful paint and the cumulative layout shift metrics in there, but you don't have the FID metric presented in Lighthouse. But is there maybe a proxy that developers can use to check for an FID or a value that's close to that so that they can start working on getting their FID metrics better? Yeah, that's a great point. And the thing about FID, or first input delay, is that it requires some sort of interaction. And the way Lighthouse actually traces a site, right, like it's doing it manually. There's no way to actually indicate an actual click or an interaction. So there's other ways, I think, that are sort of better to measure first input delay. There's a library called Web Vitals built by Philip on my team. And what that does, it actually provides an easy wrapper around the performance observer APIs so that you can always hook it to any site. And the idea is if you wanted to measure first input delay on your site, you could easily just include the getFID function from include the right polyfills if the browser needs it, and then you can log it to your console or even send it to Google Analytics or anywhere else. And that way you can actually start measuring first input delay as you're trying out your own site. Like I mentioned earlier, there's tools like the Chrome User Experience Report that allows you to measure this in the past 30 days on your site by all the users or access on your site. There's also even a Chrome extension that someone on my team also built that allows you to also just see the values. And again, it will require that user interaction, and you can open that Chrome extension. And I think it's called the Web Vitals Chrome extension. And you can see that first input delay value show. So there's definitely other ways besides Lighthouse. And it's definitely important to realize, OK, this requires some interaction. Let me see if I can actually find out. All right. And yeah, just to confirm, that's exactly how the extension is called, because I'm using that quite frequently. OK. Thank you for that. So we have a couple of minutes left. I would like to take this opportunity. I would give you 10 seconds to think about your answer. If there would be one single thing that you would recommend people to remember in terms of what we discussed today, like one thing that they can go and change today on their website, what would that be? What would be one thing? Or maybe use a web page or do this or do that. What would be the thing that you would tell them to do after this call or after this day at the conference? So I'm going to start with Cassidy. I would say get rid of the code that you're not using and any code that you're shipping to the browser that's not actually running as much as possible. There's a lot of things like, for example, media queries. I think they're great for styling pages and adding breakpoints and stuff. But they were kind of designed for a time where things weren't as mobile. A lot of actual business and things were being run on a phone. And there's a lot of things that you can do with your code where you can take out certain elements of it, but you can also just not render certain things on the page. Instead of hiding it with CSS, you could say, you know what, I'm actually just going to say if a page is a certain size, I'm just not going to render this component in React or something. And getting rid of that code that runs on the page as much as possible is the thing that will help your site be more performant. Okay. Perfect. Eric? I would say it's nothing you can do with your site, but something you can do with your team, which is have some process. The best thing you can do maybe is actually hook it up to a build process or something. Like Cassidy was saying, you can do it in Netlify. But hook some sort of performance metric tool up to something that's going to get run regularly that people will look at. Because there's the old engineering adage that you can't what is it? You can't see what you're you can't improve what you can't measure or something. I'm screwing that up. But anyway, just being able to see problems and see improvements over time is the most more impactful than any individual change. And it'll drive more and more changes going forward. As the platform evolves, as your understanding of what performance best practices evolves, and as your product evolves. So, yeah. Okay. Perfect. Thank you, Eric. And last but not least, Hussain. Would it be okay if I said I was going to say exactly what Eric said? Automate automation, I think. That's fine. Yeah. So, just I think just understanding that automating everything that you can is going to be the best way to improve performance. Lighthouse has a CI tool that you can use, WebPageTest has a GitHub hook that you can use. And I think there's so many examples of that to just sort of make sure you're seeing performance change over time. And even if the frameworks and bundlers you're using, find out ways within those tools to automate as well. Is there a component like the Next.js image component that allows you to optimize images without doing any work? And the list goes on. So, I think that is one thing I'll definitely say is the most important thing to think about. All right. Perfect. Well, thank you very much to all of you. Thank you very much for joining me on this panel. So, this was Cassidy, Eric, and Hussein. Thank you very much. Thank you for having me. You will find all our details. Thank you. All of our details, I think, on the conference page. Sorry, I heard some voices in my earpiece. So, you will find all our Twitter handles, I think, on the conference page. So, feel free to... And I'm speaking for all of you now. So, feel free to reach out for us for any questions in terms of web performance and core web vitals. I hope you enjoyed this panel and do enjoy the rest of the conference. Thank you.