How to fix slow INP

What INP measures

Tap something. INP is the time from that tap until the browser paints the next frame showing a response. It covers three phases, and they fail for different reasons:

• Input delay — the main thread was busy with something else, so your tap sat in a queue. This is the load-time problem: a script parsing, a framework hydrating.
• Processing time — your event handler running. Long handlers, expensive state updates, synchronous storage access.
• Presentation delay — the browser recalculating style and layout for a large DOM before it can paint the result.

Find out which phase is slow

Chrome DevTools’ Performance panel, recorded with 4× CPU throttling on, will show you a long task with the interaction sitting inside it. But the fastest way to see the real distribution is to log it from live traffic:

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) {
    if (e.duration > 200) {
      console.log(e.name, Math.round(e.duration), e.target);
    }
  }
}).observe({ type: "event", durationThreshold: 200, buffered: true });

Run that on a page you suspect and use the site normally for a minute. The elements that print are your problem, in your own hands, on your own device — and on a mid-range Android they will print a lot more often.

The fixes that actually move it

Audit your third parties honestly

Open the Lighthouse third-party summary. For each entry, ask who asked for it and what happens if it goes. Live chat widgets that load on every page for the 0.3% of visitors who open them are the classic case: load the button, and only load the widget when the button is clicked. Session recorders and heatmap tools are the next worst offenders.

Break up long tasks

Anything over 50ms blocks input for its whole duration. Yield back to the browser between chunks of work so a queued tap can jump in:

// After each meaningful chunk of work
await scheduler.yield?.() ?? new Promise((r) => setTimeout(r, 0));

Separate the visible response from the real work

The visitor needs feedback in the next frame, not the finished result. Update the UI first, then do the expensive part:

button.addEventListener("click", () => {
  showSpinner();                    // paints on the next frame
  requestAnimationFrame(() => {
    setTimeout(() => doExpensiveWork(), 0);
  });
});

Ship less JavaScript in the first place

Input delay during load is the largest single contributor to bad INP on content sites, and it is almost entirely a question of how much script has to be parsed and executed before the page will listen. Code-split by route, drop polyfills for browsers you no longer support, and check whether you are shipping the same library twice.

Watch the DOM size

Presentation delay grows with the number of nodes the browser has to restyle. A page with 5,000 elements — common with page builders — will be sluggish however tight your JavaScript is. Virtualise long lists rather than rendering all of them.

A caution about the number

Because INP takes the worst interaction rather than the average, a single expensive control can dominate. That cuts both ways: it means one fix can move the number a long way, and it means an improvement to your most common interaction may show up as nothing at all. Check that your load-time scripts are in order at the same time — they set the floor everything else sits on.