How to Improve INP: Practical Ways to Reduce Interaction Latency

In this guide, we at Talha Aslan and team walk through the order we follow in real audits when we improve INP for clients. First, we clarify what the metric actually measures. Then we look at the usual suspects one by one: long tasks, heavy JavaScript, third-party scripts, and event handlers. If you need the broader definition of the three metrics, read our Core Web Vitals overview first. Here, we focus only on interaction latency and on what you can do to improve INP in practice.

What exactly does INP measure?

INP observes the latency of interactions across the entire visit, not just the first one. According to the web.dev INP documentation, the reported value is the longest interaction observed, ignoring outliers. In other words, one fast click does not save the score; the worst experience decides it.

Three types of interactions count:

• Mouse clicks.
• Taps on a touchscreen.
• Key presses on a physical or onscreen keyboard.

On the other hand, hovering, zooming, and scrolling do not count toward INP. The documentation also defines an outlier rule: it ignores one highest interaction for every 50 interactions. Most pages have fewer than 50 interactions, so in practice the worst one usually becomes the reported value. Therefore, a single heavy menu button can drag down the whole page.

INP replaced First Input Delay (FID). FID only measured the input delay of the first interaction. INP, by contrast, considers all interactions and their full latency. As a result, it is a stricter but more honest measure of responsiveness.

What are the good, needs improvement, and poor thresholds?

Google evaluates the thresholds at the 75th percentile of field data, with mobile and desktop split apart. That means three out of four visits should stay under the target. The table below summarizes the limits from web.dev.

These limits can change, so always check the current values on web.dev and Google Search Central. Also, keep mobile and desktop results separate. A page that looks fine on desktop can easily fall into the poor range on a mid-range phone. For that reason, we always check the mobile row first in our audits.

Which three phases make up an interaction?

Every interaction latency is the sum of three parts. The web.dev guide to optimizing INP builds on this split because each part needs a different fix.

1. Input delay: The wait between the user action and the moment event handlers start to run. Long tasks on the main thread often cause it.
2. Processing duration: The time the event handler callbacks need to run.
3. Presentation delay: The time from the end of the callbacks until the next frame appears on screen.

For example, if an add to cart button feels slow, first find out which phase is long. A long input delay means other code holds the main thread. If processing duration is long, the button code itself is heavy. A long presentation delay means the browser struggles to redraw a large DOM tree. In short, the right diagnosis keeps you from spending effort in the wrong place.

Why do field data and lab data disagree?

Field data comes from real users. Lab data comes from one test on one device and one network. The web.dev article on lab and field data differences explains this in detail. For INP, the key point is simple: a lab test cannot know when a user will click.

According to that article, Total Blocking Time (TBT) is a proxy, not a substitute for INP. Moreover, a page can have poor INP despite very good TBT scores. So give priority to field data and use the lab only for diagnosis.

How do you measure INP from your own visitors?

CrUX data is valuable, but it does not tell you which button is slow. That is why the web.dev guide treats a real user monitoring (RUM) setup as the best starting point. With your own monitoring, you can record which element each slow interaction happened on.

In practice, we suggest collecting three pieces of information:

• The element involved, for example a filter box or a menu button.
• The interaction type: click, tap, or key press.
• How the latency splits across input delay, processing duration, and presentation delay.

Example scenario: on example.com, monitoring data shows that most of the worst interactions happen in the mobile menu. Instead of auditing the whole site, the team can then focus on one component. Also, avoid collecting personal data while you set this up. The goal is to understand the interaction, not the person. If you have no monitoring yet, CrUX data in PageSpeed Insights fills part of the gap.

How do you find INP problems in Search Console?

The Core Web Vitals report in Search Console shows real user data for mobile and desktop separately. According to the Search Console Help documentation, the report groups similar pages and gives each group one status: Poor, Need improvement, or Good.

The worst metric among LCP, INP, and CLS sets the status of the group. The data comes from the CrUX report and reflects the last 28 days. Consequently, a fix you ship today will not show up in the report right away. The report is also a sample of indexed pages, not a complete list.

If you are opening the report for the first time, start with our Google Search Console guide. If your property is new or traffic is low, the data screen may stay empty; we cover that case in our post on not enough usage data. When you open a URL group, you see example URLs. Those examples are the best hint about which page to test in the lab.

Why is INP usually worse on mobile devices?

Mobile devices usually have less processing power than desktops. The same JavaScript takes longer on a phone, so the number of long tasks grows. That is why the mobile row in Search Console often looks worse than the desktop row.

The web.dev lab and field article also points to an interesting detail. On pages that are not optimized for mobile, the browser can add a delay between a tap and the event handler. That delay is not a long task, so TBT does not capture it, yet it raises INP. According to the article, setting a proper mobile viewport avoids this delay.

In practice, test on the kind of mid-range phone your audience uses, not on the fast laptop of your team. Also, review mobile behavior in general. For example, measure how much work menus, sliding panels, and sticky bottom bars do at the moment of interaction. That way, you can separate device limits from code problems more clearly.

How do you reproduce a slow interaction in the lab?

Field data tells you which page group has a problem. However, it rarely tells you which button is slow. So the second step is to reproduce the issue in your own browser. The web.dev guide recommends testing common user flows by hand.

• Open the menu, pick filters, fill in the form, and add a product to the cart.
• Try these interactions while the page is still loading, since the main thread is often busiest then.
• Run the test on a mid-range phone or with CPU throttling in the browser.
• Record a performance trace in developer tools and inspect the long tasks and the interaction track.

Example scenario: an online store on example.com shows poor mobile INP. The team starts a recording and taps the filter box on a category page. The trace reveals that the filter redraws the entire product list. As a result, the problem shrinks from "the site is slow" to one specific function. For general use of lab tools, see our post on the Lighthouse performance test.

What are the most common mistakes when teams try to improve INP?

We see the same mistakes again and again when teams try to improve INP. The first one is watching only the lab score. The Lighthouse score goes up, the team thinks the job is done, and the field data stays flat. That happens because the moment a real user clicks never occurred in the test.

The second mistake is fixing the whole site at once. This approach burns developer time. It also hides which change actually helped. Instead, pick the template with the most traffic, prove the result there, and then move to the next template.

The third mistake is trusting desktop results. Fast team laptops hide the problem. The fourth is switching off tracking tags blindly, which breaks the marketing data. Finally, teams often ship the change and forget to start validation. In short, planning, measurement, and follow-up need to move together.

How do you reduce input delay?

Input delay is the time a click waits in line. If the browser is busy finishing another job, your click has to wait. So the fix is to keep the main thread free. The web.dev guide recommends limiting the script evaluation that happens at startup and cutting down on long tasks.

In practice, we ask a few questions. Does the page load code it does not need right away? Is an invisible section loading its scripts up front? Does a timer keep running code that occupies the main thread? Also, do analytics and ad tags do extra work at the moment of a click?

For example, a comment widget at the bottom of the page does not need to load immediately. If you load it when the user gets close to that section, startup work drops. Then the first clicks do not have to wait. We describe the general toolkit of code splitting and deferral in our post on how JavaScript affects site speed. Here, the goal is only to free up the moment of interaction.

Why do long tasks hurt INP?

According to the web.dev article on long tasks, any task that takes longer than 50 milliseconds is a long task. The main thread can only process one task at a time. Therefore, a click that arrives during a 300 millisecond task waits until that task finishes.

Long tasks usually come from these sources:

• Parsing and running large JavaScript bundles.
• List and table code that builds hundreds of elements in one go.
• Analytics, ad, and chat scripts that all run at page load.
• UI frameworks that recalculate the entire state on every click.

That said, a long task is not a bug on its own. The trouble starts when it collides with a user interaction. So the goal is to split big jobs into smaller pieces and give the browser room to breathe in between. The next section explains exactly how.

How do you yield to the main thread?

Yielding means pausing your work briefly so the browser can handle more important tasks. The pending click runs, the screen updates, and then your code continues where it stopped. Web.dev treats this as one of the main techniques to improve INP.

The documentation describes two approaches. One option uses setTimeout to move the rest of the work into a new task. However, deferred work goes to the end of the queue, so other waiting tasks run first. The second is scheduler.yield(). According to the documentation, its continuation gets priority. As a result, code from other sources, such as third-party scripts, cannot interrupt the order of your work.

For browsers without support, the documentation suggests a setTimeout based fallback or a ready-made polyfill package. It also states clearly that it no longer recommends the isInputPending() approach. One line from the guide is useful in daily work: yielding indiscriminately is better than not yielding at all. In other words, do not wait for perfect timing; even splitting one long loop makes a difference.

How do you make event handlers lighter?

If processing duration is long, the problem sits in the code of the element the user clicked. The web.dev advice is clear: do the visual update first and defer the rest. The user should see right away that the click worked.

For example, think about an add to favorites button. Ideally, the heart fills instantly. The save request to the server, the analytics event, and the refresh of a recommendation list can run a few hundred milliseconds later. The guide describes a setTimeout inside a requestAnimationFrame callback for this. That way, the browser paints the visual change in the next frame, and the heavy work follows afterward.

• Remove unnecessary handlers attached to the same event.
• In search boxes that query on every key press, wait for a short pause before sending the request.
• On click, update only the part that changed, not the state of the whole page.
• Move heavy calculations to a web worker where possible.

As a result, processing duration drops and the user gets feedback. Moreover, these changes are often code edits that leave the design untouched.

How does heavy JavaScript affect efforts to improve INP?

Heavy JavaScript is the most common obstacle we meet when we work to improve INP. The bigger the bundle, the longer the browser spends parsing, compiling, and running it on the main thread. Every click that arrives during that time waits.

In an audit, we first look for unused code. The coverage view in developer tools shows code that loads at startup but never runs. Next, we look for chances to split bundles per page. For instance, checkout code does not need to load on the home page.

On the other hand, generating large amounts of HTML on the client is risky too. The web.dev guide warns that rendering a lot of HTML with JavaScript can increase presentation delay. So content you can prepare on the server should not wait for the browser to build it. This helps both loading and interaction. If you want the bigger picture on speed and rankings, our post on how site speed affects SEO adds that context.

How do third-party scripts slow down interactions?

Tools for analytics, ads, chat windows, heatmaps, and cookie notices add code you did not write. These scripts share the same main thread. Consequently, even if your own code is light, a third-party script can start a long task at the moment of a click.

Here we look at this topic only from the INP angle. Our practical checklist looks like this:

1. List every tag in your tag manager and remove the ones nobody uses.
2. Decide on which pages each tag is truly needed.
3. Load tools such as chat windows after the first user interaction.
4. Measure in a performance trace how much work click listeners do on every click.
5. For scripts you cannot remove, check whether the vendor offers a lighter loading option.

However, turning off conversion tracking is not a solution. The goal is not to give up measurement. Instead, the goal is to keep measurement from making users wait. Marketing and development teams need to sit at the same table to find that balance.

How can you reduce presentation delay?

Presentation delay is the time the browser needs to prepare the next frame after your code finishes. The browser calculates styles, works out layout, and paints the screen. A more complex page means a longer wait.

The web.dev guide gives two main tips for this phase. First, keep the DOM small. Second, use the content-visibility CSS property to lazily render elements that are off screen. Then the browser deals only with the visible part.

For example, in a long product list you can focus on the visible cards instead of drawing hundreds of them at once. Also, animations that affect large areas and heavy shadow or blur effects can raise paint cost. So design decisions affect INP too. For that reason, we share performance findings with the design team as well.

Why do DOM size and layout thrashing matter?

Layout thrashing happens when code changes the style of an element and then reads its size or position in the same task. In that case, the browser has to recalculate layout immediately. The web.dev guide calls this forced synchronous layout and advises you to avoid it.

The problem usually shows up inside a loop. For example, code that reads a height for each card and then writes a new height forces a fresh layout on every step. If you group all reads together and all writes together, the browser finishes with one calculation.

A large DOM tree also raises the cost of every style change. Menus, hidden tabs, and unused modal windows pile up extra nodes. Therefore, when you clean up, look beyond visible content to the hidden structures that sit and wait. In short, a leaner page paints faster and brings fewer surprises.

How do you improve INP on sites built with ready-made themes?

On sites that use ready-made themes and page builders, the work to improve INP looks a bit different. Much of the problem code is not yours; it comes from the theme, a plugin, or the page builder. So instead of rewriting code line by line, you first build an inventory.

We follow this order. First, we list the active plugins and check which pages each one loads scripts on. Next, we test interactive components such as sliders, tabs, and popups in a performance trace. After that, we remove components nobody needs and load the rest only where they matter.

Also, caching and minification plugins often help loading metrics, but they rarely fix INP on their own. INP is not about how fast code downloads. Instead, it is about how much work the code does at the moment of a click. So do not install a plugin and assume the problem is gone; always confirm with field data.

What does a step-by-step plan to improve INP look like?

We put our field-tested plan into one list. The order matters because each step narrows the target of the next one.

1. Pull the mobile URL groups with INP issues from the Core Web Vitals report in Search Console.
2. Choose example URLs from each group and rank them by traffic value.
3. List the common interactions on those pages: menu, filters, forms, cart.
4. Reproduce those interactions in a performance trace with CPU throttling.
5. For every slow interaction, note the share of input delay, processing duration, and presentation delay.
6. Split long tasks and move the visual update to the front of event handlers.
7. Remove or defer third-party scripts you do not need.
8. Shrink the DOM and fix code that causes layout thrashing.
9. Ship the changes and start validation in the report.
10. Watch field data for the next 28 days and log any regressions.

If you want a team to run this plan on your site, our SEO consulting service covers the technical audit, the task list for your developers, and the follow-up afterward. That way, the fix does not happen once and then fade away.

How do you validate the fix in Search Console?

After you ship the fix, you start validation from the related issue row in the report. According to Search Console Help, you click Start Tracking to begin a 28-day monitoring period. If the issue does not appear on any URL during that window, it counts as fixed.

Validation statuses include Started, Passed, and Failed. A failed result means the issue still exists on some URLs. In that case, go back to the example URLs and test again to see which interaction is still slow.

Also, set realistic expectations. Since the data reflects the last 28 days, the improvement appears gradually. In the first days, older visits still weigh on the numbers. So do not roll back a fix just because nothing changed after a week. Keep watching until the improvement you confirmed in the lab shows up in the field.

Does a good INP guarantee better rankings?

No, it does not. The Google Search Central page on Core Web Vitals highly recommends that site owners achieve good Core Web Vitals. It says this aligns with what core ranking systems seek to reward, along with other page experience aspects. Still, page experience is only one of many signals.

In other words, if content quality, search intent match, and trust signals are weak, a fast page will not climb to the top by itself. On the other hand, between two pages of equal quality, the one that does not keep users waiting is clearly better for visitors. That is why we recommend INP work for user experience and conversion health, not as a ranking promise.

To see where speed fits in technical SEO as a whole, our technical SEO tips give the general frame. For the loading side, see our LCP guide; we do not repeat that topic here.

When should you bring in a team for this work?

Outside help makes sense when one plugin does not solve the INP issue, when the issue repeats across several templates, or when your developers do not know what to fix. On online stores in particular, lag in filters, the cart, and checkout can mean lost users.

We do three things in this work. First, we build a priority list from field data. Next, we write a concrete task for every slow interaction, in terms your developer can act on. Finally, we track the changes through the validation period and report regressions. A new plugin, a campaign tag, or a theme update can break INP again. For that reason, we recommend a monthly check instead of a one-time fix, so you catch issues before users notice them.

We do not promise rankings. However, we track the issue in a measurable way. If you want to solve INP on your site and keep it under regular review, request a quote on our SEO consulting page. We then clarify the scope based on your site structure and send you a fitting work plan. The quote lists which templates we review, which task list your developer receives, and how we report the follow-up.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.