How to Improve Interaction to Next Paint (INP)
Almost always JavaScript blocking the main thread. Here is how to find which script, and what to do about it.
Short answer
INP is main-thread congestion. Find the long tasks in Chrome DevTools, then reduce them: defer non-critical JavaScript, cut third-party scripts, break up long-running work, and remove event handlers doing expensive work on every interaction.
INP replaced First Input Delay in 2024 and is harder to pass, because it measures every interaction during the visit rather than only the first one. A page that loads fast and then feels sticky will now fail.
What it is actually measuring
The time between a user interacting — tap, click, key press — and the browser painting the visual response.
If the main thread is busy running JavaScript, it cannot paint. The user taps, nothing happens, they tap again. That is what INP captures.
Target: under 200ms.
Finding the cause
Chrome DevTools → Performance. Record while interacting with the page. Look for long tasks — blocks over 50ms — and see what is in them.
PageSpeed Insights field data tells you whether you have a problem. DevTools tells you what it is.
The usual causes
Too much JavaScript, executing too early
Everything parsed and executed at load competes for the main thread. Defer anything not needed for first interaction.
On WordPress this frequently means plugins loading their scripts on every page rather than only where used. A slider plugin's JavaScript running on your contact page is pure main-thread cost.
Third-party scripts
Chat widgets, analytics, tag managers, heat-mapping, ad scripts, consent tools. Each one is code you did not write running on your main thread.
- Load them after interaction where possible — a chat widget can initialise on first click rather than on page load
- Audit them periodically; scripts accumulate and nobody removes them
- Be aware tag managers can load anything, and often do
Expensive event handlers
A handler doing layout-triggering work on every scroll or input event will make the page feel broken. Debounce, throttle, or move work off the interaction path.
Large DOM
Tens of thousands of nodes make every style recalculation expensive. Page builders produce deeply nested markup and this is one of the ways it costs you.
Practical fixes, in order
- Audit third-party scripts. Usually the largest and easiest win.
- Defer non-critical JavaScript. Nothing that is not needed for first paint should block it.
- Load per page, not globally. Plugin scripts only where the plugin is used.
- Break up long tasks. Yield to the main thread rather than running 300ms of work in one block.
- Reduce DOM size. Structural, and usually means addressing the page builder.
The WordPress-specific version
- Check what is enqueued on each template and dequeue what is not needed
- Look hard at anything adding admin-bar or analytics scripts to the front end
- A caching plugin does not help INP — caching addresses server response, not main-thread work
That last point catches people out. Caching fixes TTFB and helps LCP. It does nothing for INP, because the JavaScript still runs in the visitor's browser either way.
Core Web Vitals explained covers where INP sits among the three, and why is my WordPress website slow covers the broader diagnosis.
Related services
Related reading
Website Performance
Core Web Vitals Explained for Business Website Owners
Three metrics, in plain English — what each one measures, what breaks it, and which number Google actually uses.
Website Performance
Why Is My WordPress Website Slow?
Four kinds of slow, four different causes. Work out which one you have before changing anything.
Website Performance
Website Speed Optimisation Checklist
Ordered by impact rather than alphabetically, so you fix the thing that matters before the thing that does not.
Website Performance
How to Reduce Server Response Time (TTFB)
Everything else on the page waits for the first byte. How to find out why yours is slow, and what actually brings it down.