 Hi everyone, I'm Annie Sullivan and I'm Michael Mockney we're engineers on Chrome web platform team Our team focuses on the core web vitals metrics and today we want to talk to you about interaction to next paint As you heard in the keynote Interaction to next paint or INP for short is set to replace first input delay as a core web vital in In this talk, we're going to review the background from last year's talk on what INP is Then dig into a demo where we show you how to optimize it and finally show you some real-world examples of how sites optimize their own INP First let's start off with a recap from last year's talk If you'd like to watch the whole talk click the video link in the corner The core web vitals metrics are designed to measure your sites performance and user experience You can check your site scores and get recommendations to improve in tools like page speed insights the chrome user experience report lighthouse and chrome dev tools There are three core web vitals metrics Largest contentful paint measures how long it takes a web page to load Cumulative layout shifts measures how much content unexpectedly shifts around the page and first input delay Measures how long it takes for the page to start processing the first user interaction First input delay is the metric we feel needs an update It has some major gaps that we want to address First it's very focused on the initial page load only measuring the very first interaction on the page But 90% of user time on a web page is spent after the initial load Second it only measures the time until the browser starts processing the interaction So we have introduced INP to replace it as a core web vital INP measures the time from each tap Click or key press on the page until the next update to the screen We feel it captures the user experience of a web page much better than first input delay Here's an example of the type of frustrating user experience that INP captures The user tries to click on the menu, but it's slow to respond and it looks like nothing happened So they click again, but it turns out the first click did open the menu only slowly and now their second click Closes it again. I've had this happen to me before and it's very annoying When the user clicks the same spot multiple times in a row like this It's called a rage click and it's a sign of user frustration in Chrome We see that on page loads with poor INP times users are much more likely to rage click So how do you make sure that your page has snappy interactions and happy user? First you need to look at how your site's doing You can see how fast interactions for real users in Chrome are using page speed insights or the Chrome user experience report They'll break it down so you can see how many of your users are getting experiences that are good need improvement or poor But what do you do if your users are seeing poor INP? Michael has put together a demo to help us dig into understanding and improving interactions Michael take it away Thanks, Annie. Hi folks. I'm Michael and I work with Annie on the Chrome web platform speed metrics team I have a bit of a passion for sailing which means I always find myself day-dreaming about sailboats That's why I decided to take this opportunity to create a very simple app about boats Nothing fancy just the search box with autocomplete search results I'll be searching through some JSON data entirely client-side here At this point, I haven't implemented proper search yet, but let's go see what the app shell feels like For now when I type into the search box only random results appear below I'll fix that in a moment, but how's the app performing? It certainly feels pretty snappy to me, but how can I know exactly how so? Let's use INP to measure Now I could jump immediately into the performance panel in DevTools But I prefer to do that only once I know I have something specific to diagnose When I'm just getting started debugging interactivity I find it helpful to just monitor the performance of each individual interaction as it happens For that, I like to use console logging which you can find in the web vitals Chrome extension Or you can add your own logs using JavaScript. Let's take a look I've already added the INP JavaScript snippet to this page So I can see a real-time log of each part of every interaction Ideally most interactions would come in under a hundred milliseconds, but the threshold for a good INP is 200 Looks like this is performing very well so far. So let's go implement search As a first attempt, let's create a simple filter results function We'll call this function from our autocomplete component every time we get a new search term It will search through all items in our JSON, assign a score to each, and then sort so that we can show the top results Let's try that out Hmm, well the search results certainly look a lot more accurate, but now the app suddenly feels a lot more sluggish I don't mean that it just takes a while to load in search results over the network or something I mean, I can't even see what I'm typing because the page goes completely frozen That's what INP measures the ability of the browser to show changes at all This feels painful and looking at the console the INP metric reflects that too The problem is our filter results function is slow and it blocks every one of our rendering updates What we really want to do is to split the update Update the search box first quickly maybe add an animation or progress indicator and then start working on search results afterwards So let's change our code to leverage a few common patterns available to most UI frameworks First let's add a suspense boundary between these two components This allows the search box to render its update without waiting for autocomplete Second let's wrap the autocomplete state change inside of a start transition Transitions are requests to update state, but without blocking existing UI Finally, let's also debounce this effect meaning instead of crunching through search results Right away for each and every keystroke. Let's delay a short while until I stop typing Debouncing is a very common technique with lots of library support Though it's not always built into frameworks. Let's try that Much better now I can see things happening the text updates quickly and I added some CSS to blur the search results whenever they're stale It still takes a while to get fresh results, but at least it feels like something is happening. That's a huge improvement Except it looks like I'm still getting hiccups sometimes. How come? I think it's time to reach for that performance panel All right, I've already recorded a trace which I know captured some slow interactions. So let's dive in Notice we have an interactions lane that visualizes every single interaction If you hover over one interaction, you will see its total duration This one looks like the longest What I'd really like to answer quickly is Where's my delay even coming from? Is it input delay from other tasks totally unrelated to my interaction? Or do I have long running event handlers because of my interaction? Was there expensive rendering work like style and layout? Maybe I even had rendering delays off the main thread like decoding large images or expensive css effects This time it looks like this is a case of input delay This long task here was preventing my keyboard input event from even beginning to run So where did it come from? At first glance it looks like it may be caused by my framework But if you look carefully all the real time was spent inside our filter results function Which was actually still running back from the previous search Debouncing the work into the future fixed that interaction, but it's now affecting this interaction All right So we started with every interaction being slow and we did our best to debounce that long task into the future That did improve responsiveness for many interactions But that work still has to run eventually And once it does it blocks everything Now UI frameworks do their best to drive efficient state changes to time slice work To segment UI updates and to abort needless transitions But none of that can happen if our own code is long running and blocking the main thread This is an unfortunate and common pattern on too many pages today So let's make some final changes First let's change our filter results function to be async We'll need to change our UI component when we do so, but these days this is getting a lot easier to do Now that it's async we can follow a pattern Let's periodically yield to main using scheduler dot yield API or a polyfill like I have here That gives other work a chance to run in the middle of our function here Allowing events to fire and browser rendering to happen Finally for this demo I chose to go one step further and added support for aborting any in-progress work as soon as I start typing again using an abort controller With these changes filtering search results won't be a dangerous long task anymore Because of that I can even remove the debounce delay that we added earlier Since now it doesn't matter if I get started eagerly or with every keystroke We'll get faster results to the user and we'll still stay responsive the best of both worlds I can't wait to try this version Look at that. I can type into search as much as I want whenever I want and search results are being filtered one bite-sized chunk at a time No more hiccups blocking the page at all And our imp scores are looking great All right With that I think I'm ready to deploy Then I'll be eagerly waiting to get field data back to confirm users are seeing the same great benefits I saw here if not I'll have to reach for field insights to help me go back and try again Now let's look at imp in the real world We'll go over some case studies of real websites that have made big improvements to responsiveness for their users Let's start with the economic times They began their work in lighthouse cutting down their total walking time Total walking time measures how much time the main thread is blocked during page load And it's correlated with interaction to next paint Because main thread slowdowns are the main cause of slow user interactions Lighthouse offers a lot of advice for improvement and the team found several places to make headway They late loaded scripts, which are not business critical to free up the main thread to process the main content They removed unused javascript and css, which are still parsed and compiled even when they're not needed As part of this process they inlined the necessary css Because over 90 of their common css was not getting used This made a big improvement and they kept going once they had optimized the total walking time They look for things that would specifically improve interactions First they reduce the dom size This can really improve the time it takes to render after an interaction And speaking of re-rendering they avoided unnecessary re-rendering But upgrading to next js to take advantage of better react hooks to avoid re-rendering They took advantage of request title callback to render below the full content when the main thread is freed up And they use party town to move third-party code off of the main thread After all of these optimizations Economic times saw imp on their topics pages reduced by 75 This big improvement in user experience translated to big improvements to business metrics They saw a 50 decrease in bounce rate and a 43 uplift in page views With this success economic times is going to press forward with this work Scaling these improvements site-wide Another great example is red bus red bus is india's largest online bus ticketing platform Millions of people use the website on their phone to book bus tickets and not all of them have the fastest phones Those users that didn't have fast phones were seeing some really high interaction times So red bus added real user monitoring using web vitals js to understand which elements had the slowest interaction time And then dug into the problems They reduced the amount of render blocking css and javascript They reduced the amount of data sent in api calls saving lots of time processing and filtering They removed unneeded javascript and css that were still slowing down interactions After fixing all of these issues and adding some other optimizations They cut their imp in half and users love the results Red bus saw a 7.2 increase in conversion rate We're really excited about the big improvements to business metrics that red bus and the economic times saw when they improved their imp We really hope you'll try it out yourself We put together a lot of resources to help you get started Please follow the link in the slides to learn more Thank you so much for watching