Four changes that actually reduce INP
INP can look fine in the lab and fail in the field. Here are the four interventions that work in production.
Quick answer
INP (Interaction to Next Paint) measures the delay between a user interaction and the next screen update. Under 200 ms is considered good. The four most common causes are long JavaScript tasks, heavy event listeners, unnecessary re-renders and third-party scripts.
Measure first, then intervene
The frustrating thing about INP is that lab tools do not surface it. Without measuring real interactions by real users on real devices you cannot know which interaction is slow. So every INP engagement starts with collecting field data.
1. Break up long tasks
Any JavaScript task over 50 ms blocks whatever interaction arrives while it runs. Splitting large work with scheduler.yield() or requestIdleCallback often produces a visible improvement on its own.
2. Lighten event listeners
Heavy work bound to scroll and input events runs at exactly the moment the user is interacting. Throttle it, or defer it to the next idle frame.
3. Cut unnecessary re-renders
In component-based UIs a single state change can re-render dozens of unrelated components. This is the most common reason a screen updates late after a button press.
4. Discipline third-party scripts
In most projects we measure, more than half of main-thread time goes to analytics, chat and ad scripts. Deferring them — or moving them server-side entirely — usually beats optimising your own code.
Related content
A checklist for migrating without losing traffic
Most migrations are lost in preparation, not on launch day. Here is the checklist we use.
What is GEO? A practical introduction to generative engine optimization
Classic SEO competes for a ranking; GEO competes for a place inside the answer. Here is the difference and wha...
How to build a topic cluster: a worked example
Moving from a keyword list to a topic cluster is the step most content programmes skip. Here it is with a conc...