Beyond First Load Speed with INP

Rate this content
Bookmark

In this talk, we will go on a journey in the future of the core web vitals potential member INP, which will help in improving the interactions in all interactions in the session's lifetime, not only the first input delay as in the FID, showing some case studies and a way to optimize your website for INP, you will go away with a bunch of recommendations to do immediately

8 min
15 Nov, 2023

AI Generated Video Summary

The Talk discusses the Core of Vitals and IMP, which are metrics used to measure user experience in browsers. IMP measures multiple actions such as tab, click, and key press until the next screen updates. It also addresses the issue of rage clicks and their impact on user experience. The Talk emphasizes the importance of optimizing for IMB by avoiding blocking the main thread and suggests using multiple tasks and yield to main thread for optimization. Additionally, it mentions the use of navigatorScheduling.isInputPending to handle user input, with a caveat that support may vary across browsers.

1. Introduction to Core of Vitals and IMP

Short description:

Today, I'm going to talk 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. 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. And the third one is First Input Delay, or for short, it's FEDs. Some of them cannot be measured using synthetic testing, as I will explain in a bit. 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. 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.

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.

2. Measuring and Optimizing IMB

Short description:

IMB measures blocking tasks on the main thread, causing input delays. It includes input delay, processing time, and presentation delay. IMB should be under 200 milliseconds for good performance. To optimize for IMB, avoid blocking the main thread. Break down long tasks into separate functions and use yield to main thread to run them in different tasks.

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.

3. Optimizing Main Thread and Handling User Input

Short description:

To optimize the main thread, you can implement multiple tasks instead of one long task. Another solution is to use navigatorScheduling.isInputPending to check for pending user input before yielding. However, support for this solution is better in Chromium than in Safari and Firefox. Consider implementing a fallback for users on different browsers.

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.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
JSNation 2023JSNation 2023
26 min
When Optimizations Backfire
Ever loaded a font from the Google Fonts CDN? Or added the loading=lazy attribute onto an image? These optimizations are recommended all over the web – but, sometimes, they make your app not faster but slower.
In this talk, Ivan will show when some common performance optimizations backfire – and what we need to do to avoid that.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
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 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.