How to Fix Interaction to Next Paint (INP) and Total Blocking Time (TBT) Issues

Download Presentation Slides

Interaction to Next Paint (INP) Defined

Interaction to Next Paint (INP) is a Core Web Vitals metric that measures a web page’s responsiveness (latency) from when a user interacts with the page to when the browser reflects that interaction visually.

A common example I like to use to understand INP is the mobile menu on your WordPress site or an accordion. Google measures how much time it takes from keypress to fully open (or how long the visual update takes). This includes mouse clicks, taps, and key presses. Scrolling and hovering aren’t measured.

• It is classified as an official Core Web Vitals metric as of March 2024, replacing First Input Delay (FID). Only INP, LCP, and CLS are official metrics that you must pass or fail. Every other metric is a notable metric, something that might impact them.
• Why is it important? INP is all about the user experience. Lowering the INP should result in it feeling faster (perceived performance) when navigating around a site.

INP Components

INP is made up of three components:

1. Input Delay (event handler fires)
2. Processing Time (callback functions for the event)
3. Presentation Delay (even handler finishes execution, browser presents frame)

Event: A button click on a webpage.

Example: The oven timer buzzes in a restaurant kitchen. ⏲

Event Listener: JS code that’s set up to watch for the button click.

Example: The kitchen assistant, who is always alert, hears the timer. ????

Event Handler: The function that runs when the button is clicked, which might change the text on the button, show a message, trigger other action, etc.

Example: The assistant alerts the chef. The chef then turns off the oven, takes the dish out, and prepares it for service.

You can see all the event listeners on a page in Chrome DevTools. And this is where TBT and blocking the main thread comes into play, which impacts INP. The more extensive tasks take more time, CPU, etc.

What is good INP?

According to Google, they want you to have your INP under 200 ms.

They use the 75th percentile to determine where you stand. 75% of the visits/crawls need to meet the “good” threshold for you to get that classification.

You really want to aim for lower than 200 ms because Google uses throttled 4G for mobile when crawling your site. They are purposely measuring your site using a slow connection to ensure users across the board have a good experience, not just those on a fast connection. So, you want to account for any spikes or variances.

Measuring INP (real-use data only)

It’s important to understand the difference between lab data and real-user data in PageSpeed Insights. Lab data is at the bottom of the report under the “Diagnose performance issues” section. This top section is real-user data. It’s collected over an average of 28 days as users hit your site and are recorded for Core Web Vitals.

Unlike other metrics (LCP, FCP, CLS, etc.), there is no lab data for INP, only real-user data. Why? Think about INP; it requires data from multiple user interactions on the page to determine the longest INP duration. Therefore, there is no single instance of lab data that would really be helpful or applicable.

Pay attention to this tab to see if there is enough data for your individual URL. otherwise, the origin (average) of your site is shown. A low traffic site might not have any data at all.

The real-user data are really the only metrics that matter. It’s what you pass or fail on, not lab data.

How to measure INP

If INP is only from real-user data, how do you measure and test it? There are a few different ways.

PageSpeed Insights is always a great way to grab the real-user data and if you’re passing INP.

INP Debugger tool from Debugbear won’t pick up everything, as it’s kind of a one off test (with a few clicks). It’s not the same as real-user data over time. However, it can be an easy way to test INP on your website and quickly identify the UI elements that are causing the slowest user interactions.

In this example, on our own site, they detected our cookie prompt and mobile menu as some of the slowest UI interactions. This makes sense, as these are really the only moving elements. They also measured interactions on some of our links, but these were much quicker, between 10-20 ms.

Google Search Console is a tool you should have hooked up for every WordPress site you run. It’s a great way to get notifications on URLs that need improvement, such as those failing INP thresholds.

Another cool tool from Google that many don’t know about is their CrUX Dashboard. You can use this to get an overview of your INP data over a period of time. This is assuming your site has data available.

You can also use different methods in Chrome Devtools:

• The new performance tab in Chrome 129 lets you monitor live data versus real-user data. See tutorial.
• Do a recording trace for individual INP Interactions.
• Lighthouse tab and timespan trace. Perflab is a new tool designed to make reading traces easier.

There are also a few Chrome extensions you can use to measure INP. I haven’t found these to be super accurate. But again, every data point helps sometimes to spot

things.

• Web Vitals Chrome extension (see tutorial)
• Site Speed Chrome extension from Debugbear

You can install the Chrome extension and basically set it up to log all INP interactions using the Web Vitals library as you browse around the site.

However, as of January 2025, the Web Vitals extension is being discontinued. Mainly because all the live data is now in the new Performance tab in Chrome Devtools. They are working to add more data, such as sub-part times (the three components) and script attribution for INP (source).

While all of these previous methods are pretty useful to spot really bad INP or give you an idea of where to start, the best way to really trace INP (across a whole site at once) is to use a Real User Monitoring (RUM) tool/service. The downside is many of these tools aren’t cheap.

Basically, you install the tool (script) on your site and let it continuously monitor all the interactions over a period of time. This essentially will more closely mimic the real-user data you’re seeing in PageSpeed Insights because it’s tracking everything, not just a looking at single interaction that may or may not be the issue.

Many of these utilize the Long Animation Frames (LoAF) API which can help identity exactly which scripts are contributing to rendering delays. And because they have so much data gathered from your site, they will also let you drill down into the specific elements and actions.

• DebugBear (docs)
• SpeedCurve (docs)
• New Relic (docs)
• Cloudflare (docs, pretty basic still, no individual INP elements yet, however it’s most likely coming)

Debugbear is my favorite of all the tools. They also have a 14-day free trial (no credit card required), so you can give it a try first to see if it helps track down your issue. Trust me, you’ll get more data with this tool than any of the other methods.

A few things Debugbear can help you find:

• Quickly spot the worst URL offenders.
• Primary domains causing the INP. If it’s coming from a third-party script or ad network like Mediavine, Raptive, etc., this is super handy.
• Identify specific user interactions that are slow bylooking at what page element the user interacted with.
• Breakdown of INP by elements in a table.
• Breakdown of your worst INP by element type (links, images, buttons, content, etc.)

Total Blocking Time (TBT) defined

Before we dive into how to improve INP, it’s important to understand total blocking time (TBT), as they kind of go hand in hand. TBT is a metric that measures how long the main thread of a webpage is blocked during the longest period of time when the page is loading.

Imagine your webpage as a busy chef (main thread). When it’s cooking (loading), it sometimes needs to focus on a task for a while (long task: over 50 ms). During this time, it can’t take new orders from customers (user interactions).

TBT measures how long the chef is too busy to take orders during the most critical phase when customers (users) are waiting to interact with the menu (the webpage).

This is classified as a notable metric. It’s not an official Core Web Vitals metric. Only INP, LCP, and CLS are official metrics that you must pass or fail.

Why is it important? The goal is to minimize this time so that the webpage feels responsive. If TBT is too high, it means users have to wait too long before they can click, scroll, or type.

TBT impact on INP and thresholds

How does TBT impact INP? If a user interacts with a page during a period where the mainthread is blocked (as measured by TBT), the browser will need to wait for these long tasks to finish before it can process the interaction and update the UI.

• Delayed Processing: The longer the main thread is blocked, the more likely it is that user interactions will have to wait, increasing the time before the next visual update can occur.
• Visual Feedback: INP includes not just the input delay but also the time for the next paint, which provides visual feedback to the user. High TBT can result in a high INP because the browser might not be able to paint the next frame promptly, making interactions feel sluggish.

Imagine clicking a button that should change color immediately but also trigger a complex operation. If the main thread is blocked by TBT at that moment, the color change (part of INP) could be noticeably delayed, leading to a poor user experience.

Minimizing TBT is incredibly important for reducing delays in INP, ensuring that when a user interacts withyour webpage, they receive prompt visual feedback.

According to Google, they want you to have a TBT of 200 ms or less. It accounts for 30% of the score.

Improving TBT/INP: Reduce JavaScript execution time

The first thing you can do to improve TBT/INP is to reduce JavaScript execution time. You can use a feature like Delay JavaScript in our Perfmatters plugin.

You can see the massive TBT difference:

Remember, INP can be measured at any point, so delaying JS isn’t necessarily always helping with that. But the goal is to get the TBT down as much as possible regardless.

Improving TBT/INP: Minimize main-thread work

• Delay JavaScript on user interaction
• Minify JavaScript
• Minify CSS
• Remove unused CSS
• Disable plugins that shouldn’t be loading sitewide (Script Manager)

All of these things can be done in our Perfmatters plugin.

There are multiple things you can do to minimize the main-thread work.

And remember, it’s important to keep your HTML doc size as small as possible too. Not everything always needs to be inline.

Improving TBT/INP: Avoid long main-thread tasks

For long main-thread tasks, you can again utilize the Delay JS feature in Perfmatters. I also really like using Debugbear for this. For example, you can see third-party CPU time and hover over long task durations to see the contributing URL. Great for troubleshooting third-party scripts that might be causing long main-thread tasks.

WebPageTest and Third Party Explorer are also handy to analyze CPU time.

Improving TBT/INP: Reduce the impact of third-party code

For third-party code, one of the best options you have is to either remove it or delay it on user interaction. Unfortunately, there might not always be a quick fix or way to optimize the code itself.

Many sites that are running ad networks like Google Adsense, Raptive (AdThrive), BlogHer, Mediavine, etc., typically have higher TBT and then in turn worse INP. In fact, we’ve seen higher INP on every ad network site we’ve worked.

Also, remember that while delaying JS on user interaction might help resolve some of the TBT, it might not always fix INP issues, as this can be measured at any point in the load. Or rather, don’t think of Delay JS as a quick fix for INP related issues.

Improving TBT/INP: Avoid an excessive DOM size

What can you do to decrease the HTML doc size and reduce the number of DOM elements? Here are a few quick pointers.

• Use lightweight themes and solutions coded with performance in mind. This will automatically result in lower DOM elements/depth, not to mention all the other benefits.
• I recommend GeneratePress (One), Kadence and Kadence Blocks, or Bricks. I can’t stress this enough. I think Kyle will agree. Once you move to these solutions, you’ll never go back.
• Don’t just inline everything possible. I see a lot of tendency to just inline all the CSS, and this can easily lead to a really large HTML doc. Using external stylesheets allows them to be cached separately.

The same goes for inline SVG code. Remember, with SVGs as an image, you can lazy load them.

• Pay attention to the number of HTML elements on your pages or posts. For example, I was working with a client who didn’t realize they had thousands of spam comments. This quickly added up to over 60,000 DOM elements on a single post and page size of over 700 KB.
• One obvious solution is to consider the length of your pages. Instead of adding 5 rows of products on a WooCommerce site homepage, perhaps cut that back to 2 or 3 rows. That will reduce the DOM/number of elements.
• You can utilize the Script Manager in Perfmatters to disable scripts, stylesheets, or entire plugins where they might not be needed or shouldn’t be loaded. MU mode includes inline CSS/JS.

Speaking of DOM elements, we have a new feature in our Perfmatters plugin called Lazy Elements.

The more HTML elements you have, typically, the more time is spent, leading to higher TBT. It can be a tricky thing to optimize in WordPress as you can’t just remove DOM elements, which make up the structure of a page.

However, you can lazy load selective elements. Think of it just like lazy loading an image below the fold, in this case, you can lazy load an element chain below the fold, reducing the overall DOM size.

Improving INP: Additional tips

When it comes to optimizing INP, almost everything depends on how much JavaScript and CPU time is involved with your user interactions on elements. That means the quality of the code you’re running matters, along with how many third-party scripts you’re using.

We can’t stress enough how important it is to use quality lightweight themes and plugins that were built with performance in mind from the ground up. Even a small component, such as an accordion coded in the wrong way, can impact INP (see example).

When it comes to Perfmatters specifically, if you’re using our Delay All Scripts feature, we recommend using our advanced Disable Click Delay option.

Having more dynamic elements can easily hurt you. Always avoid things like animations, sliders, popups, whenever they aren’t absolutely necessary.

If you’re running a lot of third-party scripts, one way to reduce the main thread is to utilize a tool from Cloudflare like Zaraz to offload the JavaScript entirely to the edge. This essentially means it wouldn’t block the main thread (potentially reducing INP/TBT). Cloudflare has already built apps/services like Google Analytics, tracking pixels, etc. Definitely something to experiment with.

Quick summary of INP and TBT

• INP is all about the web page’s responsiveness on interaction to paint.
• Extensive tasks and more complex event handlers can result in higher INP.
• Google wants your INP under 200 ms.
• There is no lab data for INP, only real-user data. And that is because it’s measured based on multiple user interactions with the site over time.
• There are some tools to measure INP on the fly, but a RUM tool is the best way to really pinpoint INP problems.
• TBT and INP go hand-in-hand.
• Google wants your TBT under 200 ms.
• Utilize Delay JS in Perfmatters to significantly decrease your TBT time. But remember that due to how INP is measured, it might not always reduce INP.
• Other optimizations like minifying JS, minifying CSS, and removing unused CSS can help.
• Disable plugins or scripts that shouldn’t be loading sitewide using a tool like the Script Manager.
• Third-party ad networks almost always cause higher INP.
• Reducing the DOM size does help; you can also utilize Lazy Elements in Perfmatters.
• Experiment with a tool like Cloudflare Zaraz to offload the JS entirely to the edge (not in the browser) which can help reduce INP/TBT by not blocking the main thread.

It’s also important to remember that not everything has to be perfect. Real-user data can take a while (up to 28 days) to come in. So sometimes your INP fixes might not show up right away in terms of passing or failing. You can monitor this in PageSpeed Insights using the “origin” tab or in Google Search Console.