Fix INP: make your site respond faster to taps

INP, short for Interaction to Next Paint, is the Core Web Vital that trips people up. LCP and CLS are about what the page looks like as it loads. INP is about how it feels once it is there. Tap a menu, and if nothing happens for half a second, that lag is what INP captures.

I have fixed this on a fair number of sites. The causes rhyme, so here is how I work through it.

What INP actually measures

When a user interacts, the browser has to run your event handlers, then paint the result. INP looks at the delay across all interactions in a visit and reports a value near the slowest one. A single janky click can sink the score, so you are hunting for the worst offender, not the average.

The target is 200 milliseconds or less for 75% of real visits.

Step one: measure with real users

Lab tools like Lighthouse cannot click around your site the way a person does, so they estimate INP poorly. You want field data.

• The Chrome User Experience Report gives you the 75th-percentile INP for your origin.
• Real-user monitoring in your analytics gives you per-page numbers and, if you log it, which element was slow.

Start there. Fixing what you cannot measure is guesswork.

Step two: find the long tasks

Open the Performance panel in Chrome DevTools, start recording, and interact with the slow part. Look for long tasks, the blocks over 50 milliseconds that hold up the main thread. Those are where the browser is too busy to respond.

Common culprits:

• A big handler doing layout, network, and state updates all at once.
• Third-party scripts running work on every interaction.
• Rendering a large list or component synchronously after a click.

Step three: cut the delay

A few moves handle most cases.

• Break up long tasks. Split heavy work so the browser can paint between chunks. Yield to the main thread with await on a scheduler, or defer the non-urgent part.
• Do less on the handler. Update what the user sees first. Push logging, analytics, and secondary state to after the paint.
• Defer non-critical JavaScript. If a script does not need to run before the first interaction, load it later. On WordPress I built QueueForge to hold heavy scripts until the first user interaction, which takes that work off the critical path.
• Keep third parties honest. Audit what each embed costs on interaction. Drop or delay the ones that are not worth it.

The mindset that helps

Treat responsiveness as a budget. Every script you add spends from it. Before shipping the next widget, ask what it costs the first tap. That question alone keeps most sites in the green.