Chrome uses First Input Delay (FID) as part of Core Web Vitals (CWV) to measure the load responsiveness of websites. FID measures the waiting time from the first user interaction to the moment the browser is able to process the event handlers connected to the interaction. It does not include the time to process the event handlers, process subsequent interactions on the same page, or paint the next frame after the event callbacks run. However, responsiveness is crucial to the user experience throughout the page lifecycle because users spend roughly 90% of the time on a page after it loads.
INP measures the time it takes a web page to respond to user interactions from when the user starts the interaction until the moment the next frame is painted on the screen. With INP, we hope to enable an aggregate measure for the perceived latency of all interactions in the page's lifecycle. We believe that INP will provide a more accurate estimate of web pages' load and runtime responsiveness.
Since FID measures only the input delay of the first interaction, it is likely that web developers have not proactively optimized the subsequent interactions as part of their CWV improvement process. Sites, especially those with a high degree of interactivity, would therefore have to start working hard to do well on this metric.
The role of frameworks
Frameworks may have taken steps for better responsiveness by improving FID for websites earlier. However, they would now have to analyze the available responsiveness metric data and work towards addressing any gaps identified. In general, INP tends to have lower pass rates, and the difference in the measurement process requires additional code optimization. The following table summarizes why.
|Measures the duration between the first user input and the time when the corresponding event handler runs.
|Measures the overall interaction latency by using the delay of the
|Main thread availability to run the event handler required for the first interaction. The main thread could be blocked because it is processing other resources as part of the initial page load.
|Main thread availability and size of the script executed by the event handlers for different interactions, including the first interaction.
|Primary cause for poor scores
|Similar to FID for every interaction plus usage of rendering patterns that prioritize key UX updates over other rendering tasks.
The Aurora team in Chrome works with open-source web frameworks to help developers improve different aspects of the user experience, including performance and CWV metrics. With the introduction of INP, we want to be prepared for the change in CWV metrics for framework-based websites. We have collected data based on the experimental responsiveness metric in CrUX reports. We will share insights and action items to ease the transition to the INP metric for framework-based websites.
Experimental responsiveness metric data
The table shows the percentage of origins on each framework with a good responsiveness score. The numbers are encouraging but tell us that there is much room for improvement.
Third-party scripts: Third-party scripts, which are sometimes not required to process an interaction (for example, ad scripts), can block the main thread and cause unnecessary delays. Prioritizing essential scripts can help to reduce the negative impact of third-party scripts.
Multiple event handlers: Multiple event handlers associated with every interaction, each running a different script, could interfere with each other and add up to cause long delays. Some of these tasks may be non-essential and could be scheduled on a web worker or when the browser is idle.
useTransitionso that part of a component render is in the next frame and any more costly side-effects are left to future frames. Given this, updates in a transition that yield to more urgent updates like clicks can be a pattern that can be good for INP.
Prefetching: Aggressively prefetching the resources needed for subsequent navigations can be a performance win when done right. If however, you prefetch and render SPA routes synchronously, you can end up negatively impacting INP as all of this expensive rendering attempts to complete in a single frame. Contrast this to not prefetching your route and instead kicking off the work needed (for example,
fetch()) and unblocking paint. We recommend re-examining if your framework's approach to prefetching is delivering the optimal UX and how (if at all) this may impact INP.
From now on, for a good INP score, developers will have to focus on reviewing the code that executes after every interaction on the page and optimize their chunking, rehydration, loading strategies, and the size of each render() update for both first-party and third-party scripts,
How are Aurora and frameworks addressing INP issues?
Aurora works with frameworks by incorporating best practices to provide baked-in solutions to common problems. We have worked with Next.js, Nuxt.js, Gatsby, and Angular on solutions that offer strong defaults within the framework to optimize performance. Following are the highlights of our work in this context:
React and Next.js: The Next.js Script component helps to address issues caused due to inefficient loading of third-party scripts. Granular chunking was introduced in Next.js to allow for smaller-sized chunks for shared code. This helps to reduce the amount of unused common code that is downloaded on all pages. We are also working with Next.js to make INP data available as part of their Analytics service.
Angular: Aurora is partnering with the Angular team to explore server-side rendering and hydration improvements. We also plan to look into refinements in event handling and change detection to improve INP.
Vue and Nuxt.js: We are exploring avenues for collaboration, mainly in relation to script loading and rendering.
How are frameworks thinking about improving INP?
React and Next.js
React.js time slicing, implemented through
Suspense, allows you to opt-in to selective or progressive hydration. This means that hydration isn't a synchronous block. It's done in small slices that are interruptible at any point.
This should help improve INP and enable you to respond more quickly to keystrokes, hover effects during the transition, and clicks. It also helps to keep React apps responsive even for large transitions such as auto-complete.
Next.js has implemented a new routing framework that uses
startTransition by default for route transitions. This allows Next.js site owners to adopt React time-slicing and improve the responsiveness of route transitions.
The Angular team is exploring several ideas that should also help with INP:
- Zoneless: Cuts down on initial bundle size, and required code that must load before an app can render anything.
- Hydration: Island-style hydration to limit how much of the app needs to be woken up for interaction.
- Reduce overhead of CD: For example, make change detection less expensive, find ways to check less of the app, and leverage reactive signals about what's changed.
- More granular code-splitting: Make the initial bundle smaller.
- Better support for loading indicators:: For example, during SSR re-render, during route navigation, and in lazy loading operations.
- Profiling tools: Better dev tools to understand interaction cost, particularly around change detection cost for specific interactions.
Through these enhancements, we can address different issues that lead to poor responsiveness and user experience, and boost the CWV metrics and the new INP metric for framework-based websites.
We expect the INP score to provide a better compass for websites to improve responsiveness and performance in the future. We will build on our existing INP guide to provide more actionable tips for framework developers in 2023. We hope to achieve this by:
- Creating channels for easy access to field data on INP for frameworks and web developers.
- Work with frameworks to build features that will improve INP by default.
We welcome feedback from framework users as they begin their INP optimization journeys.