How to Improve Interaction to Next Paint

What INP measures

INP looks at the clicks, taps and key presses made during a visit, not only the first one, so a single slow filter or menu can set the value for the whole page. Google's threshold is 200 milliseconds or less for a good experience ^[1]. It took over from First Input Delay on March 12, 2024 ^[2]. It is a harder test than FID because it measures the whole time until the next frame is painted, not just the delay before the first handler starts.

Desktop sites usually do well on INP. HTTP Archive's 2025 Web Almanac found 97% of desktop websites had good INP, but only 77% of mobile websites ^[3]. Phones have slower processors, so the same JavaScript takes longer to run.

The three phases of an interaction

web.dev splits each interaction into three phases ^[4]:

1. Input delay: the time from the interaction until its event callbacks begin running. This grows when the main thread is already busy with other work.
2. Processing duration: the time the event callbacks take to run.
3. Presentation delay: the time until the browser paints the next frame showing the result.

Knowing which phase is long tells you what to fix. Long input delay points to other scripts hogging the main thread. Long processing points to your own event handlers doing too much. Long presentation delay points to expensive layout and rendering work.

Finding the slow interactions

Field data tells you whether INP is a problem and on which device type, but not which interaction is slow. To find it, reproduce likely interactions in Chrome DevTools with CPU throttling on, since DevTools can approximate low- and mid-tier mobile devices ^[5]. Good candidates are menus, filters, add-to-cart buttons, form fields with validation, accordions and anything that opens a modal. Record a performance trace and look for long tasks that start right after the interaction.

Fix 1: break up long tasks and yield

A long task blocks the main thread, so the browser cannot respond or paint until it finishes. The fix is to split the work into smaller pieces and give the browser a chance to handle input and paint between them. web.dev recommends breaking event callback work into separate tasks, for example with setTimeout, and states that "yielding indiscriminately is better than not yielding at all" ^[4]. A common pattern is to do the minimum needed to show feedback first, such as opening the menu, and defer the rest, such as logging an analytics event.

Fix 2: send less JavaScript

"Avoid unnecessary JavaScript" is one of Google's three top recommendations for INP ^[6]. Script evaluation itself can create long tasks that block the main thread ^[4]. In practice that means:

• removing libraries that are no longer used or duplicated;
• loading feature scripts only on the pages that need them;
• replacing heavy components with lighter ones where possible;
• delaying non-essential third-party scripts until after load or until they are needed.

Fix 3: review third-party tags

Chat widgets, analytics, heatmaps, advertising and review tools all run on the same main thread as your site. web.dev's tag guidance notes "a correlation between the size of tag managers and poorer INP scores" and recommends removing unused tags, delaying non-essential ones and keeping containers small ^[7]. Our third-party scripts guide covers how to audit them.

Fix 4: avoid large rendering updates

Some interactions trigger a lot of layout work: re-rendering a long product grid, changing classes high in the DOM, or reading layout values in a loop while writing styles. web.dev warns against large DOMs and forced synchronous layout, which it calls "a performance bottleneck" ^[4]. Keeping the DOM smaller, updating only what changed, and batching reads and writes all reduce presentation delay. Google also lists "avoid large rendering updates" among its top INP recommendations ^[6].

Fix 5: give feedback immediately

When an action genuinely takes time, such as submitting a form, show something straight away: a pressed state, a spinner or a short message. That gives the browser a frame to paint quickly while the slower work continues, which helps both INP and how the page feels.

Checking the result

Test the same interactions under the same throttling before and after each change. Lab traces confirm the improvement quickly. Field data takes longer, because PageSpeed Insights reports the previous 28 days ^[8]. If Search Console flagged INP, start validation after the fix; the report runs a 28-day monitoring session ^[9].

A worked example: a slow filter

Consider a fictional store category page. Tapping a "Price: low to high" filter takes about 600 milliseconds on a throttled phone before the grid updates. A performance trace shows three things. First, an analytics script is still running from page load, so the tap waits about 150 milliseconds before the handler starts: that is input delay. Second, the handler sorts 200 products, rebuilds the whole grid's HTML and logs an event, all in one task: that is processing duration. Third, replacing the grid forces the browser to lay out and paint every card again: that is presentation delay ^[4].

The fixes follow the phases. Delay the analytics script until after load so the main thread is free sooner. In the handler, show a "Sorting" state immediately, then yield, then sort and update only the cards that move, and send the analytics event afterwards. Keep the grid's DOM lean so layout is cheaper. Each change is small; together they bring the interaction under the threshold. None of it changes what the visitor sees, only when they see it.

Where INP problems hide on typical sites

The last row is worth highlighting. When a visitor accepts cookies, consent tools often release every waiting tag at once, so the click that dismisses the banner can be one of the slowest interactions on the site. Spreading those tags out, or loading non-essential ones a little later, helps.

Frameworks and page builders

Sites built with JavaScript frameworks or heavy page builders tend to have more main-thread work, both at startup and after interactions. That does not make them slow by default, but it means INP needs deliberate attention: avoiding large re-renders after small changes, splitting code so pages load only what they use, and keeping hydration work out of the way of the first interactions. Google's top recommendations for INP, yielding often, avoiding unnecessary JavaScript and avoiding large rendering updates, apply whatever the tool ^[6].