 Hi, I'm Annie, and I'm here with Michael. We're both engineers on the Chrome web platform team. And we want to welcome you to the state of responsiveness on the web. What is responsiveness? Well, simply stated, it means understanding how quickly web pages respond to user input. For example, when I try to open the menu on a website, how long does it take before it appears to be doing something at all? Or, perhaps, I click a button to add an item to my car on a shopping website. How long after I interact before I can actually see that my item is being added? Annie, I have a recent encounter with responsiveness. It's actually not related to the web at all. You see, my car has a cruise control feature, which I can use to maintain vehicle speed automatically. Before I can use the system, I have to press a button to turn the system on. Nice and simple. Except last year, I upgraded to a new vehicle, and this one has adaptive cruise control. Now, my car uses a myriad of sensors, 360-degree cameras, artificial intelligence, and even math to help me drive. It's actually pretty amazing. Of course, all those smarts come at a cost. Now, when I try to turn the system on, it takes several seconds to engage. Perplexingly, pressing that cruise control button now appears to do nothing before finally engaging. This is incredibly frustrating. It doesn't surprise me that it takes a few seconds to start, but why don't I get any feedback at all during that whole time? Sometimes, I'll press the button and wait. Unless I accidentally didn't press the button quite right, so I'm waiting around for nothing, so I'll press the button again. Except actually, I did press the button right the first time. I just didn't wait long enough, and now I've turned the system back off, so I end up sort of rage-clicking. Now, in a perfect world, the system would just always turn on instantly. But we know that can't always be possible. Instead of fully waiting for everything to finish, it should really just respond to my input with feedback, even if it takes a few more moments to fully complete. And that's what we mean by responsiveness. User interfaces should give some useful, initial response to every interaction quickly, even when they can't complete everything instantly. On the web, that means that the time from each interaction to the next paint should be reasonable, and that the feedback should be useful. Okay, Michael, it's pretty clear that poor responsiveness affects you personally, but how do we address such problems at scale? Well, first, let's look at what we have already learned from the Core Web Vitals metrics. We work to give sites a clear and simple way to measure page loads and provide a tooling to help them improve. With clear guidance came big improvements. Web developers worked diligently, and have now saved us all at least 1,000 years of waiting around while loading. And that was in Q4 alone. Instant loading makes browsing a joy, but it's really just a part of the web performance story. Actually, 90% of the time users spent on websites is after the page is loaded. And it's probably not surprising that users really tend to interact with sites after loading is complete. That's why we've been working on better measurement for responsiveness beyond load. And when we started measuring, we found out that it definitely needs improvement. We found that over 70% of users experienced terrible responsiveness at least once a week. And that was when we looked for one whole second of interaction latency with no visual feedback whatsoever. Yet we know from user experience research that 100 milliseconds is the guideline for latency to user input. This has been our responsiveness target in the rail model for years. Finally, we found that users appreciate good responsiveness a lot. We see that when a user typically experiences good responsiveness, they will regularly load twice as many pages as those of us who are regularly frustrated by high interaction latency. Alright, so we know it's important, but how do we measure responsiveness today? Well, first input delay is the current core web vital for measuring loading responsiveness. FID is actually the oldest metric of the core web vitals, already having widespread adoption nearly four years ago. FID should still be your first step to addressing responsiveness. And boy, have you ever. FID now has a 95% pass rate. What an incredible success. Developers like you have worked to reduce first input delays from simple things like widespread adoption of mobile viewports to incredibly complex changes, like the fact that popular web framework started bootstrapping JavaScript using task schedulers and they make sure to promptly yield to main thread whenever there is input pending. I mean, incredible work. FID is no longer the problem it once was. But the pass rates have not always been that high. We've seen a 13.4% improvement over those four years. But another way, users are now three and a half times less likely to visit a site with high first input delay. Okay, that's the good news. Fortunately, FID has some fairly large blind spots. Really, we know the web isn't actually 95% great at responsiveness. I mean, in your own experience, how often is the first interaction the only one that matters to you? And that's why we are introducing a new experimental responsiveness metric. Interaction to next paint. INP is a full page lifecycle metric, just like cumulative layout shift. That means it measures all interactions, not just the first. We call that runtime responsiveness to help differentiate from just loading responsiveness. INP measures the whole input latency from when a user interacts until they actually see a visual response, not just the initial delay on main thread. INP measures all important discrete interactions, including tap, drag, and keyboard. But ignores continuous events like hover or scroll. Now, because this metric is new, and we're still working with all of you to evaluate it thoroughly, we're labeling it an experimental metric for the time being. We have to admit, we hope to see it evolve to replace first input delay as a core web idol eventually. We actually already added INP as an experimental responsiveness metric to the Chrome User Experience Report, or CRUX, in March. Meaning you can already check your site's responsiveness data going back to the start of Q1 2022. We've gotten great feedback already. Thank you to everyone who has eagerly dived in. This CRUX data has helped us find sites where FID was fine, but the new INP score was poor. In most cases, when we took a look, it's been easy to uncover real responsiveness issues quickly. As one example, we found that some third-party bot detection libraries were waiting until the first interaction and then executing a bunch of heavy script. This didn't add input delay or even long tasks during load, but it certainly delayed user responsiveness heavily. This issue remained completely hidden from field metrics like FID and lab metrics like total blocking time, but was easily caught with INP. Now, if CRUX data is not enough, you could take things into your own hands and measure INP in the field using WebVitals.js library. Doing so allows you to report extra insights that CRUX cannot provide, for example, which interactions with which elements around which times are actually leading to these responsiveness issues. Precisely identifying the source of a problem is often half the value. We've also made it easy to just measure INP and your local browsing by adding it to the WebVitals Chrome extension. Finally, we're working to improve support for responsiveness in LabTooling. After all, the whole point of knowing when your site isn't meeting responsiveness targets is to quickly work to address them. Coming shortly, you will see INP field results in paid-speed insights, and we're exploring ways to add INP to the Chrome developer tools, performance panel, and Lighthouse. Even better, instead of requiring manual testing for responsiveness in the lab, you can now automate interactions and measure real responsiveness using Lighthouse user flows. If you can't invest in user flows but still just need lab automation that works out of the box, well, then the best way to predict responsiveness from the lab continues to be to just measure total blocking time, or TBT, during load. Actually, we took a look at all sites in HTTP Archive and looked at their lab measured TBT. Then we checked how well that metric predicted the real field metrics, both fit and INP. In other words, we wanted to know how often do lab and field results agree, and we found that INP is actually twice as correlated with lab measured TBT as fit is. While nothing beats just measuring your field data, this was a nice result for those of us who relied on lab automation. Okay, we've talked a lot about the benefits of INP, but how exactly is it defined? It really may be best to read our full developer documentation at web.dev slash imp, which gives a detailed explanation and links to examples and reference implementations. But at a glance, it comes down to three steps. First of all, we have to measure interactions. Each interaction may have multiple events, and those events may lead to multiple animation frames. So for each interaction, we simply report the duration of the worst performing part. Each interaction is assigned one single interaction to next paint value. Next, for the whole page lifecycle, we pick one really bad interaction. Although there may be many interactions with a site, each page load reports only that single value for INP. Now, most sites have relatively few interactions, and for this vast majority, it's fine to just measure the single worst interaction. However, some sites are very interactive, for example, text editors, or chat, or games. If you measure enough interactions, you'll eventually find some hiccups, even on a responsive site that users love. So we end up measuring a high percentile, which basically overlooks a few outliers on such sites. Again, the details are a bit tricky, and it's best to read them in the documentation. Finally, as with other metrics, we assess a site by looking at its 75th percentile scores across all page loads. On today's web, we have found that 200 milliseconds is an ideal threshold for good responsiveness. While at 500 milliseconds, it is reasonable to consider that responsiveness is fairly poor. We mentioned earlier that users expect interactions to be no more than 100 milliseconds. So why the 200 millisecond threshold, even at the 75th percentile? Well, a few reasons which come down to achievability. First, remember that we are recording all interactions across the full page lifecycle. Even on the best sites with the best devices, even when most interactions are fast and under 100 milliseconds, you will always have a distribution of latencies. We want to see improvement across the board, and especially those worst cases, not just focus on the median interaction. Second, the reality is that many users have devices that can find it difficult to achieve even this modest 200 millisecond target. In particular, we see that devices with less than 2 gigabytes of RAM begin to experience increased INP scores. We hope this metric will improve the situation, but for now, that's just the reality. Finally, it's true. Even under the best conditions, as site authors, we're just not doing a great job hitting those 100 millisecond targets. Remember that 95% FID pass rate? Well, today, only 67% of origins pass the INP threshold of 200 milliseconds. And frankly, that single number, which combines all origins, actually paints a rosy picture because many origins are either not very complex or not very interactive. As you focus on popular origins with more complex sites, well, let's just say it's clear we have another four years of improvement ahead. And that's where you get involved. Now is the perfect time to dig in. First of all, we've already heard that folks are getting plenty of value out of this metric quickly, so have at it. Additionally, it will really help us evolve this metric together if you share any counter examples. The easiest way to start measuring locally is with the Web Vitals Chrome extension, which you could find here. If you just want to try the metric out, you could visit this demo page where you can quickly interact and calibrate your own expectations for responsiveness. And if you're a site owner, we really encourage you to take a look at your existing crux results or work with your real user monitoring providers to begin measuring INP on your sites. Remember, when asked, users agreed that the Web feels unresponsive. But site owners tend to think that their site is just fine. Don't think. Check. Finally, we are especially interested in feedback about tooling. Which changes would you want to see in order to make addressing responsiveness easier? Thank you so much. We are eager to hear your thoughts, which you can share with us at Web Vitals Feedback at Google Groups.com or just focus on Twitter. Good luck, everyone!