Everything you need to know

The SEO field has no shortage of acronyms.

From SEO to FID to INP – these are some of the more common ones you’ll come across when it comes to page speed.

There’s a new metric in the mix: INP, which stands for Interaction to Next Paint. It refers to how the page responds to specific user interactions and is measured by Google Chrome’s lab data and field data.

What exactly is next paint interaction?

Interaction to Next Paint, or INP, is a new Core Web Vitals metric designed to represent the overall interaction latency on a page throughout the user journey.

For example, when you click on Add to cart button on a product page, it measures how long it takes for the button’s visual state to update, such as changing the color of the button on click.

If you have heavy scripts running that take a long time to complete, they can cause the page to freeze temporarily, negatively impacting the INP metric.

Here is the sample video illustrative how it looks in real life:

Notice how the first button responds visually instantly, whereas the second button takes a few seconds to update its visual state.

How is INP different from FID?

The main difference between INP and First Input Delay, or FID, is that FID only considers the first interaction on the page. It only measures the input delay metric and does not take into account how long it takes the browser to respond to the interaction.

In contrast, INP takes all page interactions into account and measures the time browsers need to process them. However, INP takes into account the following types of interactions:

• Any mouse click on an interactive element.
• Any tap on an interactive element on any device that includes a touch screen.
• Press a key on a physical or on-screen keyboard.

What is a good INP value?

According to Google, a good INP value is around 200 milliseconds or less. It has the following thresholds:

Google also notes that INP is still experimental and that the guidance it recommends regarding this metric is likely to change.

How is INP measured?

Google anonymously measures INP from Chrome browsers based on a sample of the longest interactions that occur when a user visits the page.

Each interaction has a few phases: presentation time, processing time, and input delay. The recall of associated events contains the total time involved to perform all three phases.

If a page has fewer than 50 total interactions, INP considers the interaction with the absolute worst delay; if it has over 50 interactions, it ignores the longest interactions per 50 interactions.

When the user leaves the page, these metrics are sent to the Chrome User Experience Report called CrUX, which aggregates the performance data to provide real-world insights into user experiences, known as field data.

What are the common causes of high INPs?

Understanding the underlying causes of high INPs is critical to optimizing your site’s performance. Here are the common reasons:

• Long tasks that can block the main thread, delay user interactions.
• Synchronous event listeners on click events, as we saw in the example video above.
• Changes to the DOM cause multiple reflows and repaints, which usually happens when the DOM size is too large (> 1,500 HTML elements).

How to troubleshoot INP problems?

First, read our guide on how to measure CWV metrics and try the troubleshooting techniques offered there. But if that still doesn’t help you figure out which interactions are causing high INP, this is where the “Performance” report from the Chrome (or better, Canary) browser can help.

• Go to the web page you want to analyze.
• Open DevTools in your Canary browser that does not have browser extensions (usually by pressing F12 or Ctrl+Shift+I).
• Switch to Performance the tab.
• Disable cache Network the tab.
• Select mobile emulator.
• Click on Record button and interact with the page elements as you normally would.
• Stop recording when you’ve captured the interaction you’re interested in.

Crank the CPU 4x using the “slowdown” dropdown menu to simulate average mobile devices and select a 4G network which is used by 90% of mobile devices when users are outdoors. If you do not change this setting, you will run your simulation using your PC’s powerful CPU, which is no match for mobile devices.

It’s a very important nuance since Google uses field data collected from real users’ devices. You may not encounter INP issues with a powerful device – this is a tricky point that makes troubleshooting INP difficult. By choosing these settings, you bring your emulator mode as close as possible to the real device mode.

Here is a video guide showing the whole process. I highly recommend that you try this while reading the article to gain experience.

What we’ve seen in the video is that long tasks make interaction take longer and a list of JavaScript files responsible for those tasks.

If you expand Interactions section, you can see a detailed overview of the long task associated with that interaction, and clicking on these script URLs will open lines of JavaScript code responsible for the delay that you can use to optimize your code.

A total of 321 ms long interaction consists of:

• Input delay: 207 ms.
• Processing time: 102 ms.
• Presentation delay: 12 ms.

Below in the main thread’s timeline, you’ll see a long red bar representing the total duration of the long task.

Below the long red progress bar, you can see a yellow bar labeled “Evaluate Script”, indicating that the long task was primarily caused by JavaScript execution.

In the first screenshot, the time gap between (point 1) and (point 2) is a delay caused by a red long task due to script evaluation.

What is script evaluation?

Script evaluation is a necessary step for JavaScript execution. In this crucial phase, the browser executes the code line by line, which includes assigning values ​​to variables, defining functions, and registering event listeners.

Users can interact with a partially rendered page while JavaScript files are still being loaded, parsed, compiled, and evaluated.

When a user interacts with an element (clicks, taps, etc.) and the browser is in the process of evaluating a script that contains an event listener attached to the interaction, it can delay the interaction until the script evaluation is complete.

This ensures that the event listener is properly registered and can respond to the interaction.

In the screenshot (point 2), the 207 ms delay probably occurred because the browser was still evaluating the script that contained the click event listener.

This is where Total Blocking Time (TBT) comes in, which measures the total time long tasks (longer than 50ms) block the main thread until the page becomes interactive.

If this time is long and users interact with the site as soon as the page is rendered, the browser may not be able to respond quickly to user interaction.

It is not part of CWV measurements, but often correlates with high INPs. So to optimize for the INP metric you should aim to lower your TBT.

What are common JavaScripts that cause high TBT?

Analytics scripts – such as Google Analytics 4, tracking pixels, google re-captcha or AdSense ads – usually cause high script evaluation time and thus contribute to TBT.

An example of a website where ads and analytics scripts cause high JavaScript execution time.

One strategy you may want to implement to reduce TBT is to delay loading non-essential scripts until the initial page content has finished.

Another important point is that when delaying scripts, it’s important to prioritize them based on their impact on the user experience. Critical scripts (eg those needed for key interactions) should be loaded earlier than less critical ones.

Improving your INP is not a silver bullet

It’s important to note that improving your INP is not a silver bullet that guarantees instant SEO success.

Instead, it’s one element among many that may need to be completed as part of a series of quality changes that can help make a difference in your overall SEO performance.

These include optimizing your content, building high-quality backlinks, improving meta tags and descriptions, using structured data, improving website architecture, dealing with any crawl errors, and many others.

More resources:

Featured Image: BestForBest/Shutterstock