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

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

Core Web Vitals are a set of metrics provided by Google to help measure and enhance user experience on websites. They include Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and First Input Delay (FID). These metrics help developers identify and optimize the most impactful aspects of site performance, such as load time, visual stability, and interactivity.

To improve performance on media-heavy sites, developers should optimize media files by choosing the right format, compressing images and videos, and using lazy loading for non-critical media. Tools like preload for critical assets and responsive image techniques also enhance media performance without sacrificing quality.

Tools like Lighthouse, Chrome User Experience Report, and Web Vitals library are recommended for monitoring and improving web performance. These tools help analyze a website's performance in both lab and real-world settings, providing insights and actionable recommendations to enhance user experience.

Next-gen image formats like WebP, AVIF, and JPEG XL offer improved compression compared to traditional formats such as JPEG and PNG. These formats help reduce the file size of images without losing quality, leading to faster load times and better performance, especially important for visually rich websites.

JavaScript frameworks like Next.js, Gatsby, and Angular provide built-in tools and features to enhance performance. These include automatic image optimization, lazy loading of components and images, and efficient data fetching strategies. By using these frameworks, developers can ensure their websites are fast, responsive, and efficient.

Web performance refers to how quickly and efficiently a website loads and operates. It is crucial because it affects accessibility, ensuring that people with different network qualities and device capabilities can access and use the site effectively. Good web performance improves user experience and accessibility, especially in regions with poor internet connectivity or less powerful devices.

Tamas Piros
Tamas Piros
Cassidy Williams
Cassidy Williams
Houssein Djirdeh
Houssein Djirdeh
31 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Introduction and self-introductions of panel members for a discussion on web performance and core web vitals. Importance of web performance in ensuring accessibility and user experience. Strategies for optimizing performance in websites with visual content such as images and videos. Tools and recommendations for measuring and monitoring site performance, including focusing on eliminating unnecessary elements and utilizing measurement tools like Lighthouse. Discussion on Lighthouse, Chrome user experience report, and core web vitals for web developers. Frameworks and libraries integrating core web vitals, metrics importance, and ongoing metric development. Community initiatives in plugin development and collaboration with framework teams to enhance performance. Chrome supports lazy loading for images, and developers discuss image formats like WebP for web performance enhancements. AVIF, JPEGXL, and JPEG are advanced image formats aiming to enhance web performance. Different methods for delivering resources to users include using the picture element with various source elements. Web Vitals library offers an easy way to measure first input delay and optimize site performance. Automating processes for performance improvement using tools like Lighthouse, WebPagetest, frameworks, and bundlers.

1. Introduction and Panelists

Short description:

Thank you for joining us on this panel today. We have Kasady, Hussein, and Eric joining the discussion on Web Performance and Core Web Vitals. Kasady is a Principal Developer Experience Engineer at Netlify. Hussein works on the Google Chrome team. Eric is a Web Platform Advocate at Cloudinary. Tomas is a developer experience engineer at Cloudinary. We'll be discussing 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.

1. Panel Introduction and Self-Introductions

Short description:

Introduction and self-introductions of panel members for a discussion on 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.

2. Web Performance and Visual Content

Short description:

Web performance is important for accessibility and ensuring that websites can be used by anyone, regardless of limitations. Despite improving device and connection capabilities, the web as a whole is getting slower. Having a performant site is crucial for users with slow internet connections. Visual content, such as images and videos, is prevalent on the web. Developers can optimize performance by considering the memory impact of media assets and prioritizing important content, like hero images.

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.

2. Web Performance and Visual Content Optimization

Short description:

Importance of web performance in ensuring accessibility and user experience. Strategies for optimizing performance in websites with visual content such as images and videos.

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.

3. Media Performance and Tools

Short description:

To improve media performance, prioritize important content, lazy load images and videos, optimize resources, and make media responsive. Tracking performance and building a culture of performance are crucial. Avoid adding unnecessary bloat to the site. Consider pre-building as much of the site as possible and use measurement tools like Lighthouse to identify areas for improvement.

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.

3. Optimizing Media Performance and Monitoring Tools

Short description:

Strategies for optimizing media performance and building a culture of performance within organizations. Tools and recommendations for measuring and monitoring site performance, including focusing on eliminating unnecessary elements and utilizing measurement tools like Lighthouse.

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.

4. Lighthouse and Performance Tools

Short description:

Lighthouse is an open source auto-editing tool that measures performance and provides scores on how well a website is performing. It helps developers pinpoint issues and improve performance. Other tools like Chrome User Experience Report can also provide performance scores on real users. Using these tools ensures that thresholds and performance standards are met.

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.

4. Measuring Web Performance and Core Vitals

Short description:

Discussion on Lighthouse, Chrome user experience report, and core web vitals for web developers.

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.

5. Lighthouse, Core Web Vitals, and Metrics

Short description:

Lighthouse is a useful open-source tool that provides insights into website visuals and allows users to create custom tests. Core Web Vitals, part of Google's Web Vitals initiative, offer metrics for measuring user experience and identifying areas of improvement. The three core metrics are Largest Contentful Paint, Cumulative Layout Shift, and First Input Delay. These metrics help developers focus on pressing issues, embed them in tools like Lighthouse and Chrome's Experience Report, and ensure a good loading experience.

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.

5. Integrating Core Web Vitals in Frameworks

Short description:

Frameworks and libraries integrating core web vitals, metrics importance, and ongoing metric development.

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.

6. Frameworks and Core Web Vitals

Short description:

Frameworks and libraries are increasingly incorporating core web vitals into their functionality. For example, the NEXT.js team collaborated with Google to include measurement capabilities within the framework. This trend is becoming more common in the industry, leading to a more performant and accessible web.

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.

7. Metrics and Frameworks

Short description:

Having three different metrics allows for measuring the most important aspects of a page's performance. Larger Contentful Paint indicates speed, Cumulative Layout Shift measures actual shifts happening, and First Input Delay measures how long it takes for a site to respond. JavaScript frameworks provide tools and techniques for creating performance websites. The developer community has been actively creating plugins and initiatives to measure performance and optimize images. Next.js is one example of a framework that has incorporated performance metrics.

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.

8. Frameworks and Performance Optimization

Short description:

The ideal state would be for tools like frameworks to ensure that developers' sites are performing without requiring additional work. For example, the Next.js team collaborated with Chrome and React teams to bake in better defaults, such as the Web Vitals, Core Vitals analytics dashboard. Efforts are being made to expand this approach to other frameworks like Angular, NUX, and Vue, providing developers with the right tools and features to measure core vitals without the need for manual optimization.

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.

QnA

Performance Metrics and Frameworks

Short description:

Quantifying metrics importance and ongoing development in performance measurement.

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?

Community Involvement in Framework Optimization

Short description:

Community initiatives in plugin development and collaboration with framework teams to enhance performance.

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.

Image Formats and Web Performance

Short description:

Chrome supports lazy loading for images, and developers discuss image formats like WebP for web performance enhancements.

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.

Frameworks, Hero Images, and Remaining Time

Short description:

Frameworks like React, Angular, and others provide features like component level lazy loading, which can improve app performance. Chrome supports image lazy loading natively. A hero image is an important type of image. Developers may be unhappy because they want a race. Time remaining: 5-10 minutes. A question for Eric about the visual graph and largest contentful paint.

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.

New Image Formats and Compression Advancements

Short description:

AVIF, JPEGXL, and JPEG are advanced image formats aiming to enhance web performance. New image formats strive to bring compression advancements compatible with the web's open nature. Implementing new formats can be achieved through tools like skoosh.app, offering optimization settings for smaller images.

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.

Next-Gen Image Formats and Web Performance

Short description:

We're in an interesting time for web images with the emergence of next-gen formats like WebP, AVIF, and JPEG-XL. These formats bring new advances in image compression to the web, providing smaller file sizes and improved performance. While WebP is about 25% better than JPEG, AVIF and JPEG-XL offer even greater gains. However, delivering these formats to users can be challenging when not all browsers support them. The picture element with media or type attributes can be used to send different resources to different users based on their browser capabilities.

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.

Resource Delivery Methods and Lighthouse Metrics

Short description:

Different methods for delivering resources to users include using the picture element with various source elements. HTTP header level resource delivery offers automation benefits over markup-based solutions for developers. Implementing strategies to optimize resource delivery can enhance user experience and website performance.

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.

Image Optimization and First Input Delay

Short description:

You can save kilobytes and potentially allow websites to load faster by reducing image size. The JAMstack and static site generators offer options for automated next-gen image delivery. Developers can use the Web Vitals library to measure First Input Delay.

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.

Web Vitals and Performance Optimization

Short description:

Web Vitals library offers an easy way to measure first input delay and optimize site performance. Cassidy recommends removing unused code to enhance site performance, while Eric emphasizes the importance of continuous performance monitoring and improvement processes.

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.

Measuring First Input Delay and Recommendations

Short description:

To measure First Input Delay on your site, include the Get FID function, polyfills if needed, and log or send the data to Google Analytics. Other tools like the Chrome User Experience Report and the Web Vitals Chrome extension can also be used. Cassidy recommends removing unused code and code that is not necessary for rendering. Eric suggests integrating performance metric tools into the build process to measure and improve over time.

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.

Automation for Performance Improvement

Short description:

Automating processes is crucial for performance improvement. Tools like Lighthouse and WebPagetest offer automation options for tracking performance changes over time. Utilize frameworks and bundlers to automate tasks, such as image optimization. Reach out to panel members for web performance and core web vitals inquiries.

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.

Automation and Performance Improvement

Short description:

Automating everything you can is the best way to improve performance. Tools like Lighthouse and WebPagetest offer automation options. Frameworks and bundlers also provide ways to automate. Components like Next.js image component optimize images without manual work. Thank you to Cassidy, Eric, and Hussein for joining the panel. Find our details and Twitter handles on the conference page. Feel free to reach out for any questions on web performance and Core Web Vitals.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.