Panel Discussion: Get to Know: Web Performance and Core Web Vitals

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 Kasady, 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 Kasady. Hi everybody. My name is Kasady 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 Jirdey, 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, thanks, 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, you know, just to get the mood. So thank you.

All right. So on a more serious note. So today we're here to talk about web performance and core web vitals.

So, 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 Kasidy, 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 introduce themselves to you. Let's start with Kasidy. Hi everybody, my name is Kasidy 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 Jirday 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 Thomas at Cloudinary where I'm the web platform advocate, 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, thanks Eric. And as Eric was saying, my name is Tomasz, 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, and 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 and async function, who's there? Just to get the mood. Thank you.

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 really care about this? And I'll go with Hussain for his 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 to 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 web page can be used by anyone at any time.

Okay. Anyone else would like to add something to that? Only 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've established that web performance is important. Now, you also mention a lot of websites out there, a lot of people using the web. We can't deny the fact that the web is also visual. So, every website that we visit is full is, you know, Cat videos, more Cat videos, videos about Cassidy doing her stuff. So, there's, you know, lots of visual content out there. So, the question is, you know, 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, you know, what options are available for them?

Eric? Yeah. So, when I think about the visual web and performance, I worked with Tumash last year on the HTTP almanac chapter on media, and the top line finding there was two-thirds of the media and website is media bytes. So, you have all the bytes as a 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, right? 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. It doesn't matter how many non-blocking paints around that image are happening.

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, web performance is important, but can we talk about why is web performance important in the first place? Why developers should really care about this? And I'll go with Hussein for this first question. For sure. Yeah. Definitely a good first question. Um, web performance in its 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 HttpArchive to try and analyze how web performance is changing over time, you'll find 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 web page can be used by anyone at any time.

Only 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 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. 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, 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 even if they have lots of images and media assets on the page? So, you know, what options are available for them? Eric? Yeah. So, when I think about the visual web and performance, I worked with Tomasz last year on the HTTP almanac chapter on media, and sort of the top-line finding there was that, you know, two-thirds of the Median website is media bytes. So, you have all the bytes of the Median 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, right? 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 the 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 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. I think the first and most important thing that people can do to improve media performance is actually to look at their 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. 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 that you can do. Then, of course, optimize your resources.

The faster you show the product that someone is 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 their 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 fold, is probably the most important and highest impact optimization that you can do. Then, of course, optimize your resources. It's kind of 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. Like, figuring out what format to use for different things is crucial. Dialing in quality settings can 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 is actually doing it manually every time they check an image or 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. You know, 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.

ANTHONY Okay, thank you. So it seems as developers have, they have a lot of work to do to create a site that is performing. So do you have any recommendations to sort of tools or, you know, 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? CASSIDY There's, 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, that's something that it's something to consider, because oftentimes the best tool that you can add is nothing. And 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, um, 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, it's easier for users of your sites to be able to use it. And, which is a silly sentence users use it. But anyway, between those things and then just all the different measurement tools, whether, whether you use Lighthouse, which I'm sure Hussein 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, where are things the slowest, where are things that you can improve here and there? So it's, 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.

The best optimization you can do is to not load something at all. 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 fold, is probably the most important and highest impact optimization that you can do. Then, of course, optimize your resources. Kind of goes without saying, but it's a really complex and 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 strikes a good balance between quality and speed. I could spend 20 minutes talking about this, but making your media responsive, which is a whole world under itself. Both to different browsers that support different formats and different device resolutions and sizes.

The good news is 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 be automated. The second most important thing you can do for media performance is to make sure that no one is doing it manually every time they check an image or video on a site. 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.

So it seems as developers have a lot of work to do to create a site that is performing. So do you have any recommendations to sort of tools or, you know, 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's something to consider, because oftentimes the best tool you can add is nothing, and 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 Hussein 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. Hussein, did you want to say something about Lighthouse? Yeah, no. Like Cassidy, I think hit the nail on the head. It's, it's, 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 auto-editing 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. 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. They're just a good forcing function to make sure that your thresholds are met and your bars are met. Again, if you don't even need to use the tools in the first place, you're doing something pretty well.

But anyway, between those things and then just all the different measurement tools, whether you use Lighthouse, which I'm sure Hussein 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. Hussein, did you want to say something about Lighthouse? Yeah, no, 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 auto editor 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 you'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 there 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 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 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? 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.

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. It actually tells you whether your image is in the next gen format, and as far as I know, it's 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. Quick joke time. Do you know how you help JavaScript errors? You console them. Okay. I'll probably stop my camera in a minute. Yeah, I should. Okay. All right. So, moving on. The other part of this discussion, we talked about performance, but let's also talk about Core Web Vitals. So, where do they come from? How are they going to help developers? Are they helping developers? Are they helping the end users? What can people do with Core Web Vitals? Let's start with Hussain.

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 identifying 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 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's Experience Report. They're all beginning to embed these metrics within these tools. And both measuring them in a lab environment and 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 to say what makes a good performance site. These metrics are a way to sort of follow that direction. Okay.

They're like the tools that I mentioned that Cassie was talking about, Lighthouse, Chrome User Experience Support, 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.

What's cool to see is that more and more frameworks and libraries are taking those kinds of core web vitals into account. 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's it makes for a more performant web. And, like Hussein 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.

Just a follow up question for you, Hussein. So you mentioned these three metrics. Could you tell us in one or two sentences what they do, what they intend to measure? Yeah. 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 accountable paint indicates speed. How fast does it take for something to render on 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. 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, right? Like 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, right? 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 involve, right? 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, trying to figure out what else can we do? Should we add more metrics? Should we change them? Should we change how they work? And this is going to be an ongoing basis.

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 Hussein was saying before, a more accessible web. And so it's, 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, Hussein. 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 essentially all the aspects or the most important aspects of page experience, right? So the first one, larger cancel paint indicates speed, how fast does it take for something to render on 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, right? So, like, how do you quantify that, right? 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, right? Like 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, right? 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 involve, right? So these are sort of initially what Chrome thought and Google thought are essential, but we're working with other browser renders, we're working with communities to try and figure out what else can we do. Should we more metrics? Should we change them? Should we change how they work? And 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, you know, 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 to get a good LCP score. I think that's a valid statement, right? So it's important. Okay. Cool. So, you know, 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 are 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. 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 are 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. OK. Anyone else has any thoughts on that? Yeah, no. I definitely want to add onto that, I think that was perfectly said. I'm glad, Kassidy, 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 Kassidy mentioned, and it's only one of the things we helped with.

We're also talking with the Angular team. We're working with the NUX 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.

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, right? Like 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, right? 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 involve, right? 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, trying to figure out what else can we do? Should we add more metrics? Should we change them? Should we change how they work? And 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 Erik 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 are 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?

Again, it's one of those things where the developer community has been kind of going all in on this. I can't tell you how many Gatsby plugins have been made to just measure performance and to optimize images and stuff. 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.

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 on 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.

So 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, so 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. So lots of tools at your disposal. What kind of image saves the day? A hero image. Okay. That was a good one. And unplanned for? Okay, go on. Sorry. No, no, it's fine.

Also, latest releases of Chrome support image lazy loading natively, as well, so you can also utilize it. So lots of tools at your disposal.

Okay, so. Really quick. Yes? What kind of image saves the day? A hero image. Okay. That was a good one. And unplanned for? Okay, go on. Sorry. No, no, it's fine. It's fine. I have another one.

So 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? Ten minutes? Five, ten minutes. Okay. So I have a question... Ten minutes, okay. So I have a question to Erik. So we talked about Visual Grab. 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 it related to web performance? Yeah. Yeah, we're at a really interesting time as far as images on the web. You know, it seems like forever we've had a very stable collection of universally supported formats, you know, JPEG, PNG, GIF, SVG. And the decision about what format to deploy and what scenario was at least, if not always 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.

OK. Awesome. And I think just to add something on top of 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. So 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. So there are lots of tools at your disposal.

OK. So yes. Really quick. What kind of image saves the day? A hero image. OK. That was good one. And on plan four. Yes! Sorry. No, it's fine. I have another one. So why are developers unhappy at their job? Because they want a race? Nice. Excellent. OK. Right. So... How much time do we have left, roughly? Let's see here. Five minutes? Ten minutes? Five, ten minutes. OK. So I have a question... Ten minutes. OK. So I have a question to Eric. So we talked about, you know, visual graph. We talked about largest content for paint.

And so now that's a format you can use anywhere, which is great, except for in old browsers. And now there's even more confusing things because you have AVIF, which was supported in Chrome, I think, last fall. And hopefully this year it's behind a flag right now in Canary. JPEGXL, 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. 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 skoosh.app. And you can just fiddle with encoding settings and just see how small these images can get in these new formats.

Of course, you want to bring those savings to users. I mean, the jury's still a little bit out on definitive, you know, this format is 20% bigger than this, and it all depends, but in general, you know, if with that disclaimer, you know, web P's maybe a quarter better, you know, can, can, can do then, then JPEG for general sorts of images and, and, and JPEG, Excel, you know, or even twice that as far as gains, so these are gains that you want to bring to your users. Uh, doing so is, it's complicated when users don't all have support because the last thing you want to ship to somebody is a broken image.

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. JPEG, 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. 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 a flag right now in Canary, JPEG-XL, which is another next generation image format.

And these, you know 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 and 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 of that. And they're really cool. You can play with them and probably the easiest way to do it is in an excellent app, a web app called Skoosh, Skoosh.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, I mean 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, Excel are even twice that as far as gain. 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 and you can have a media attribute or sorry, a type attribute. And the browser looks at that type attribute and says, oh, here's an Avif. I can actually load that.

Um, and there's a couple of ways that you can send different resources to different users. Uh, you know, one is to use the picture element, um, which has, uh, various source elements, uh, that, uh, and you can, you know, that have a media attribute or sorry, 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, I'll just, I'll just load that instead. Uh, so that's a markup based solution. You can also do it super side, uh, you know, for ages on the web, we've had the accept header, uh, which, uh, the browser advertises, Hey, server, here's what I want. Here's what I actually can load. And the servers says, oh, okay, here's, here's what I can give you. Uh, so I'll give you the best format for it that you can actually use. Uh, so, you know, that all happens at the HTTP header HTTP header level, and that stuff is, uh, easier to automate maybe, uh, then, then the markup based solutions. But, uh, but yeah, so doing the work to, to figure out how to add, you know, making your life as a developer, maybe a little bit more complex. But, but doing that for your end users, uh, is, is pretty important.

Okay. So, so to sum it up, you can save kilobytes and you can potentially allow websites a little faster as well, because the image size is going to be, uh, smaller. Right. That sums it up. Also one thing to add, right. So we, we did mention to JAMstack for, for multiple reasons. Um, you can use, you know, CDN providers for this automated next-gen image delivery, but also some of the static side generators that I use within the JAMstack have image components that can do that for you as well. So you have a lot of options, uh, in that space.

So last question, and this would go to, uh, to you Hussein if you don't mind. Um, this is back to Light House. Um, you do have the LCP, uh, and the CLS metrics, the largest content for paint and the cumulative layout shift metrics in there, but you don't have the FID metric, uh, presented in Lighthouse, but is there maybe a proxy that developers can use to do check for an FID or a value that's close to that so that they can start working on, uh, getting their FID metrics, uh, uh, better. Yeah, that's, that's a great point. And the thing about FID, um, or first input delay is that it requires some sort of interaction. And the way Lighthouse actually traces the site, right? Like it's doing it manually.

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'll also do it super 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, OK, here's what I can give you. So I'll give you the best format for it 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, you know, making your life as a developer maybe a little bit more complex. But doing that for your end users is pretty important.

OK, 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. So that sums it up. Also, one thing to add. We did mention the JAMstack for multiple reasons. You can use CDM 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 would go to you, Hussain, 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 the site, it's doing it manually, there's no way to actually indicate an actual click or an interaction. So there are other ways, I think, that are 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.

It's, it's, there's no way to actually indicate an actual click or an interaction. Um, so there's other ways I think that are, that are sort of better to measure first input delay. There's a, there's a library called Web Vitals built by Philip on, on my team. Um, 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 want it to measure for somebody on your site, you can easily just include the get FID function from, include the right polyfills if the browser needs it, and then you can log it through 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, um, the, the Chrome user experience report that allows you to measure this, you know, in the past 30 days on your site, by all the users are accessing your site. Um, and 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 person but delay value show, so there's definitely other ways besides lighthouse and it's definitely important to just realize, okay, this requires some interaction. Let me treat, see if I can actually find out.

And yeah, just to confirm, that's exactly how the extension is cool because I'm using that quite frequently. Okay. Uh, thank you for that. So we have a couple of minutes left. I would like to take this opportunity. I will give you 10 seconds to think about the answer. If that would be one single thing that you would recommend people to remember, you know, in terms of what we discussed today, like one thing that they can go and change today on their website, what would that be? How, how, you know, what would be one thing you're maybe use a web page image or, you know, do this and do that? What would be the thing that you would tell them to do after this school or after, you know, this, 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 break points and stuff, but they were kind of designed for a time where things weren't as mobile where 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 could do with your team, which is have some process, the best thing you can do maybe is actually hook it up to like a build process or something like Cassidy was saying you can do at 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, to see problems and see improvements over time is, 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 a performance best practices evolves and as your product evolves. So, yeah. Okay. Perfect. Thank you, Eric.

And the idea is, if you wanted to measure First Input Delay on your site, you could easily just include the Get FID function, 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. And 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 just 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 will 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? 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, 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 break points and stuff. But they were kind of designed for a time where things weren't as mobile, where 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 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 and 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.

OK, 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 build, you know, have some process. You know the best thing you can do maybe is actually hook it up to like a build process or something like Cassidy was saying, you can do a 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 you know, 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 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 practice evolves and as your product evolves.

Thank you, Eric. And last but not least, Usai. Would it be okay if I said, I was going to say exactly what Eric said, automate, automation, I think is key. 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. 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 Usai. Thank you very much. Thank you for having us. 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, 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 to us for any questions in terms of web performance and core web vitals. I hope you enjoy this panel and do enjoy the rest of the conference. Thank you.

So, yeah. Okay. Perfect. Thank you, Eric. And last but not least, Sussane. I want to 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.