How to Fix INP (Interaction to Next Paint): A Practical Guide

What is INP?

Interaction to Next Paint (INP) measures the delay between a user interaction — a click, tap, or keyboard input — and the next time the browser paints a visual response. It replaced First Input Delay (FID) as a Core Web Vital in March 2024.

Unlike FID, which only measured the first interaction on a page, INP captures the worst interaction across the entire page visit. This makes it a more complete picture of how responsive your page feels to real users.

Thresholds:

How INP is measured

INP measures three phases:

1. Input delay — time from when the user interacts to when the browser starts processing the event.

2. Processing time — how long the event handler runs.

3. Presentation delay — time from when the handler finishes to when the browser commits the next paint.

The largest single interaction during a page visit becomes the INP score. If a user clicks a button and nothing happens for 600ms before the UI updates, that is a 600ms INP event — regardless of how responsive everything else was.

Common causes of poor INP

1. Long JavaScript tasks blocking the main thread

The browser's main thread handles both JavaScript execution and rendering. If a JavaScript task runs for more than 50ms, it blocks everything else — including responding to user input.

When a user clicks something while a long task is running, the browser cannot start the input handler until the task finishes. That wait becomes input delay.

How to find long tasks:

Open Chrome DevTools → Performance tab → record an interaction. Look for red bars marked "Long Task" in the Main thread lane. The task's duration and call stack are shown on hover.

How to fix them:

2. Heavy event listeners

Event listeners on scroll, mousemove, or resize that run expensive DOM operations on every event fire hundreds of times per second.

Fix:

```js

window.addEventListener('scroll', handler, { passive: true });

```

3. Rendering large DOM trees

A DOM with tens of thousands of nodes takes longer to recalculate layout and paint after any change. Interactions that modify the DOM trigger a cascade of layout, style, and paint work.

Fix:

4. Synchronous DOM reads followed by writes

Reading a DOM property (like offsetHeight) forces the browser to compute layout. If you then write to the DOM, the browser must recalculate layout again. Alternating reads and writes in a loop causes "layout thrashing."

Fix:

5. Third-party scripts running on the main thread

Analytics, chat widgets, A/B testing tools, and ad scripts all compete for main thread time. If they run during a user interaction, they add to INP.

Fix:

How to check your INP score

PageSpeed Insights shows INP in the Core Web Vitals section if your URL has data in the Chrome User Experience Report (CrUX). This is field data from real users.

For pages with low traffic that do not have CrUX data, you can measure INP locally in Chrome DevTools by running the Web Vitals extension while interacting with the page.

Run a free speed check with Loadzen to see your current Core Web Vitals including INP.