 Hi everyone! I'm Annie and I'm here with Michael. We work on the team here at Google that develops the Web Vitals metrics. Today, we want to share our latest thinking on the future of Web Vitals, specifically the Core Web Vitals. As a reminder, the Core Web Vitals are the subset of Web Vitals metrics that apply to all web pages and that we believe are the most important metrics for sites to measure. In addition, Core Web Vitals are unique in that they were all designed with a couple of key principles in mind, principles we plan to stick to, even as we evolve the metrics in the future. First and foremost, each Core Web Vital measures a real aspect of user experience, so things that users can see, like how fast a page loads and how quickly it responds to user input. We don't plan to include metrics that are not a direct measure of user experience, like how many bytes of JavaScript were loaded or the timing of the network requests. Second, Core Web Vitals have measurement support across both the field for real users and the lab to get deeper insights. For any updates we make, we'll work hard to make sure that our tools and APIs give developers the insights they need to be able to understand and improve the metrics on their pages. Third, we aim for each Vital to be concise and clear. We want each metric to cover a distinct aspect of the user experience. We don't plan to cover the same experience with multiple metrics. When we announced the Core Web Vitals, we said we would evolve the metrics over time, but we also promised to do so on a predictable annual cycle. As we gathered feedback about the initial Core Web Vitals, one thing became abundantly clear. People really like having a small set of metrics that are clear across all our tooling. We really want to keep the Core Web Vitals concise moving forward. And so with every update, we're also carefully weighing the costs of changing things. So for the first annual update, we're mostly thinking in terms of smaller adjustments to improve the quality of the existing metrics and respond to feedback we've received from the community. It's still several months out, but we wanted to give you an idea of what we're thinking about so we can hear feedback. We've set up an email list, webvitalsfeedback at googlegroups.com. And we'd love if you can send us your thoughts there. Michael has put a lot of thought into where we could improve, and I'm really excited for him to give you an update on where we're at. Take it away, Michael. Thanks, Annie. First, progressive loading. As we mentioned, we've tried hard to keep the Core Web Vitals concise. But we've also gotten a lot of feedback that for years, we've been talking about how there are multiple key moments for the user as a web page loads. Largest contentful paint measures when the main content is finally visible. But getting content on screen quickly is critical too. First contentful paint measures that part of the experience. Here's an example of a page that's been highly optimized to have a quick, progressive load. I know it's subtle, but the way the text and layout come in quickly, even while the main image is still loading, really makes it feel fast for the user and really makes the content usable quickly. We'd like the Core Web Vitals to be more inclusive of this initial part of the experience, as well as when the main content loads. So we're considering adding first contentful paint as a Core Web Vital. Second, interactivity during load. To recap, first input delay measures the time from when a user clicks, taps, or presses a key until the browser starts to process that input. It's designed to capture delays that result from the main thread being busy, especially during page load. Here's a quick animation that demonstrates how an input can be delayed due to the main thread being busy during load. In this example, the visual update came quickly as soon as the main thread was unblocked. But since first input delay doesn't include the time to handle the event and update the screen, and since delay is sensitive to the timing of user input, we found that some pages can have input which feels sluggish even when they meet the threshold for a good user experience on this metric. Currently, first input delay has a threshold of 100 milliseconds at the 75th percentile. But our initial research shows that tightening this threshold to 75 or even 50 milliseconds could measure the user experience more accurately. Third, visual stability. We measure unexpected movement of page content and sum up all movements into a single score, cumulative layout shift. An individual layout shift occurs any time an element which was already visible changes its position on the page and is scored based on the size of the content and distance it moved. 2020 saw several improvements to individual shift reporting such as fixes for hidden content shifting and video controls. You can always follow along with updates to CLS and all other metrics in Chrome over at bit.ly slash chrome speed metrics changelog. We think it's important that cumulative layout shift captures layout shifts even after load. Some of the worst experiences are due to shifts later in the page lifetime such as this example here. However, we also acknowledge that CLS is not always perfect for especially long-lived pages or single page applications. Moving forward, we're looking at options that are better suited to normalizing the individual shift data for such cases. Okay, but what about bigger changes? Beyond the next update, we're thinking a lot about the user experience after the page is loaded. First, we're looking into ways to have better support for single page applications. Take a look at this example. As the user clicks through the site, it feels as if they're loading new pages, but the site is a single page app and each transition isn't counted with its own largest contentful paint or first input delay. This is a tough problem because each page can have its own method for these transitions and sometimes it's not even clear whether a transition is occurring. We're looking at how we can create metrics that work better for single page apps. Second, we also want to better capture how well a page responds to user input. Our current interactivity metric is first input delay, but it only counts the first click, tap, or key press and it only measures the time until the browser starts processing. We really want to include all the inputs on the page, not just the first, and we'd also like to include the full time until the screen updates in response to an input, not just the delay until it's begun processing. Third, we're digging deep into scrolling and animations. The best experiences on the web have very smooth scrolling and animations, but a lot of other pages feel janky. Here's an example with the same text scrolling smoothly on the left and on the right was some hiccups. When you're trying to scroll through an article to read or keep your place on a product page, these janks are really frustrating and they can add up to a poor user experience. We'd like the Core Web Vitals to reflect this. Finally, we'd love to expand the Core Web Vitals more into other areas of user experience like security and privacy or accessibility. We would love to hear your thoughts on the most important aspects of user experience that you'd like to see covered. We're giving this talk early, long before the first annual update, let alone the next, because we really want to hear your feedback. So please let us know what you think. Please email webvitalsfeedback at googlegroups.com to let us know your thoughts. Thanks so much for listening. I'm looking forward to hearing from you.