Everything you need to know

There’s no shortage of acronyms in the SEO field.

From SEO to FID to INP, these are some of the common issues you will come across when it comes to page speed.

We've got a new metric here: INP stands for Interaction to Next Paint, which tells you how your page responds to specific user interactions, and is measured by Google Chrome lab and field data.

What exactly is your next interaction with Paint?

Interaction to Next Paint (INP) is a new Core Web Vitals metric designed to represent the overall interaction latency of a page across the user journey.

for example, add to cart For buttons on product pages, we measure how long it takes for the button to update its visual state when clicked, such as changing color.

If you are running a heavy script that takes a long time to complete, it may temporarily freeze the page, negatively impacting your INP metric.

Sample video here Illustrate How it actually looks:

Notice that the first button has an immediate visual response, while the second button takes a few seconds to update its visual state.

What is the difference between INP and FID?

The main difference between INP and First Input Delay (FID) is that FID only takes into account the first interaction on a 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 into account all page interactions and measures the time it takes the browser to process them. However, INP takes into account the following types of interactions:

• Click the interactive element with your mouse.
• Tap interactive elements on devices with a touchscreen.
• Pressing a key on a physical or on-screen keyboard.

What is the appropriate INP value?

According to Google, a good INP value is around 200 ms or less. The thresholds are:

Google also notes that INP is still experimental and the recommended guidance around this metric is subject to change.

How is INP measured?

Google measures INP anonymously from Chrome browsers from a sample of the single longest interaction that occurs when a user visits a page.

Each interaction has several phases: presentation time, processing time, and input delay. The callback for the relevant event contains the total time it took to execute all three phases.

If the total number of interactions on a page is less than 50, INP considers the interaction with the longest delay. If there are more than 50 interactions, it ignores the longest interaction per 50 interactions.

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

What are some common reasons for elevated INP?

Understanding the underlying causes of high INP is important to optimizing your website's performance. Common causes include:

• Long tasks that can block the main thread and delay user interaction.
• Synchronous event listener on click event as seen in the example video above.
• Modifying the DOM will cause multiple reflows and repaints, which typically happens when the DOM size is too large (more than 1500 HTML elements).

How do I troubleshoot INP issues?

First, read our guide on how to measure the CWV metric and try the troubleshooting techniques provided there. If you still can't figure out which interaction is causing high INP, the “Performance” report in Chrome (or Canary) browser can help.

• Go to the webpage you want to analyze.
• Open the DevTools for a Canary browser without any browser extensions (usually F12 or Ctrl+Shift+I).
• Switch to performance tab.
• Disable cache Communication network tab.
• Select a mobile emulator.
• click record Click the button and interact with the page elements as you normally would.
• Once you've captured the interaction that interests you, stop recording.

Use the “Slowdown” dropdown to slow down the CPU by 4x to simulate an average mobile device and select the 4G network that is used by 90% of mobile devices when the user is outdoors. If you do not change this setting, the simulation will run using your PC's powerful CPU, which is not equivalent to a mobile device.

This is a very important nuance, because Google uses field data collected from real users' devices. INP issues may not occur on high-performance devices, which is a tricky point that makes INP debugging difficult. Choosing these settings will make the emulator state as close as possible to the state on a real device.

Here is a video guide that shows the whole process: I highly recommend you to try this out and gain some experience while reading the article.

What we can see in the video is that long tasks cause long interaction times, along with a list of JavaScript files responsible for those tasks.

Zooming in Interaction In the section, you can see a detailed breakdown of the long tasks associated with that interaction, and click on those script URLs to open the lines of JavaScript code that are causing the delays, which you can use to optimize your code.

The interaction, which lasted a total of 321 ms, consisted of:

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

Below the main thread timeline, you'll see a long red bar that represents the total duration of the long task.

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

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

What is Script Evaluation?

Script evaluation is a necessary step in JavaScript execution: during this crucial stage, the browser executes your code line by line, which includes assigning values ​​to variables, defining functions, and registering event listeners.

A user may 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 has an event listener associated with that action, the action may be delayed until the script evaluation is complete.

This ensures that event listeners are properly registered and can respond to interactions.

In the screenshot (point 2), the 207 ms delay was likely due to the browser still evaluating the script containing the click event listener.

This is where Total Blocking Time (TBT) comes in. It measures the total time that long tasks (greater than 50ms) block the main thread before the page becomes interactive.

If that time is long and the user interacts with the website as soon as the page is rendered, the browser may not be able to respond immediately to the user's actions.

Although it is not part of the CWV metric, it often correlates with high INP, so to optimize the INP metric you should aim to lower the TBT.

What are some common JavaScripts that will increase your TBT?

Analytics scripts such as Google Analytics 4, tracking pixels, Google ReCAPTCHA, AdSense ads, etc. usually increase script evaluation times and cause TBT.

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

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

Another important point is that if scripts are delayed, they should be prioritized based on their impact on the user experience: important scripts (such as those essential to key interactions) should be loaded before less important scripts.

Improving INP is not a panacea

It’s important to note that improving your INP is not a panacea that will guarantee instant SEO success.

Rather, it’s one of many items that should be completed as part of a series of quality changes that will help make a difference in your overall SEO performance.

This includes optimizing your content, building high-quality backlinks, enhancing meta tags and descriptions, using structured data, improving your site architecture, resolving crawl errors, and more.

Additional resources:

Featured Image: BestForBest/Shutterstock