Beyond First Load Speed with INP

Hello, everyone. My name is Mithat Dawood. I'm a Senior Software Engineer working for Miro and a Google Developer Expert in web performance. Today, I'm very excited to take you on a journey for a new metric called IMP added to the Core of Vitals or would be for the Core of Vitals in early 2024. But this time, it is beyond the first load speech. So let's get started.

Today, I'm going to talk about four things. First of all, an introduction about the Core of Vitals and why we needed IMP. So what IMP's measuring in the first place and how to optimize for IMP. So without further ado, Core of Vitals are a bunch of metrics that has been added to the browser in order to measure the user experience. The first one is LCP, or Largest Contentful Bind, to measure the time it takes until you load the first and biggest object in the screen above the fold. And the second one is CLS, or Commutatively Out Shift. It measures the visual stability for elements. So you don't have any shifts happening in this page after loading the page. And the third one is First Input Delay, or for short, it's FEDs. And this is the most important one that we need to talk about today. So all of them can be measured easily using either field testing or Rome testing, as we call it, using something like Pagespeed Insights and Chrome User Experience Reports or lab testing, or also known as synthetic testing, using Lighthouse or Div tools. Some of them cannot be measured using synthetic testing, as I will explain in a bit.

So gaps we find in first input delay. It has some shortage. Google find out that first input delay only for the first interaction and only until the browser starts processing. This will be explained in a bit, but the most important thing is that most of the users are not interacting to the user until it is fully loaded. So 90% of the users are not really measuring for feds, which means that it's not really a good indicator that it is a good user experience or not. So the introduced interaction to an expense or for short, IMP. IMP is to measure multiple things, tab, click, key press until the next screen updates not only for the input delay and you can find this example for a frustrating experience. If you are clicking multiple times and one element, here's our friend is clicking twice in this menu to open it because the first one didn't really interact and unfortunately the second one closed the menu for them. So this is pretty frustrating and this action is called rage clicks and the more you have rich clicks, the less experience you have and the worst the interaction to an expense will be. And that's why the IMB is coming in the first place to enhance this and lower this experience as much as possible. IMB is now created and it can be measured already in the Pagespeed Insights under the other notable metrics. But early 2024 it will be moved up to the Curve of Vitals and will contribute to your ranking on Google search.

This is measured in Pagespeed Insights or React, sorry, Chrome User Experience Report because it is requiring a real user to interact with it. However, you can measure something like TBT or Total Blogging Time in order to measure this FED or IMB. That is a good indication as well that you have a problem or not using synthetic testing.

So what does IMB is measuring? This is a normal task that you will find in any performance tab that is normal because it's under 50 milliseconds. However, in most cases, you will find a different task that is a blocking task. It's a long task, more than 50 milliseconds. Will be marked like this with a red strip. And this is called blocking task or blocking for the main thread. This means that any input is happening during this long task or blocking task will be delayed until the main thread is idle so they can interact with the user. And this is exactly the reason we have FED or IMB in the first place.

So for this example, if we have these blocking tasks in the beginning, if we consider this as the blocking tasks of loading the page. So this the first time it happens, the blocking task, but the user start interacting, this is FED. It's only measuring this part input delay until it started processing time. But IMB is measuring this full thing, input delay, processing time, presentation delay, and so on. So it's not only for the first input delay. And it's also for all the interaction for the user during the experience in your page. Not only the first one like FED. IMB based on research shows that it should be under 200 milliseconds in order to be considered as good, but anything above 500 milliseconds is considered poor or bad. you need to interact immediately.

So how to optimize for IMB? As a rule of thumb, don't block the main thread. This is the main problem that we are trying to fix here. So how to do that? Breaking down your long tasks. Here is a quick example of a function that is calling five different functions. So obviously this function is a long task, calling five different functions underneath it as you can see down there. So how to do that? How to fix it for IMB? Easily, we made a small change here. We just added all the functions in an array, loop over them and call them. But after calling each of them, we are making a small thing here. We are calling the yield to main thread. This is just a tweak, it's just a fallback like a workaround to yield to main thread using setTimeout. This means that each of these functions will run in a different task.

And as you can see now, based on this implementation, you will find five different tasks is running in the main thread instead of one long task. That's a quick way in my opinion. However, you can use another solution, navigatorScheduling.isInputPending. This means that you're not going to yield to main thread every time. You can check for this one and every time you have a pending input, you can just yield. Here's an example, you're running everything from your sitting or safe sitting function, but you're checking every time before yielding. Is there a user input pending? If no, just continue. This long task in this case is not really affecting the user experience. But if there's any delayed or pending user input, we're going to break it, run it and interact with the user and continue from there. I have to tell you that this support for this one is very good for Chromium. However, for Safari and Firefox, they are not really good. So take care when you are doing that, or at least implement your own fallback in case your users are running in a different browser than Chromium based.