INP Explained: Why Your Site Feels Slow Even When It Loads Fast

A site can paint its hero image in under two seconds, score green on the loading metrics, and still feel broken — because when a visitor taps the menu, nothing happens for half a second. That gap between the tap and the response is what Interaction to Next Paint measures, and it is the Core Web Vital that most sites fail in 2026.

What INP measures

Interaction to Next Paint (INP) is the time from a user interaction — a tap, a click or a key press — to the next time the browser paints a frame showing the result. It is measured for every interaction during a visit, and the page reports one of its slowest (technically the 98th percentile, so a single outlier on a long session is forgiven). Google assesses INP at the 75th percentile of real visits over a 28-day window, and the thresholds are:

• Good: 200 ms or less
• Needs improvement: 200–500 ms
• Poor: over 500 ms

INP replaced First Input Delay as a Core Web Vital in March 2024. FID measured only the wait before the first interaction started being processed, which almost every site passed. INP measures the whole response, for every interaction, and reports the worst. That is why sites that were comfortably green in 2023 turned amber or red overnight without changing a line of code.

The three phases of an interaction

Each interaction's latency is the sum of three parts, and each has different causes.

1. Input delay — the time between the tap and the browser being able to start your event handler. It is long when the main thread is busy with something else: a script still parsing, an analytics tag doing work, a previous interaction still running.
2. Processing time — how long your event handlers take. A menu that rebuilds half the page, a form that validates every field synchronously, a filter that re-sorts a thousand DOM nodes.
3. Presentation delay — the time from handlers finishing to the frame being painted. Large style recalculations, layout on a huge DOM, and expensive paint work all live here.

Most failing sites have problems in the first two. The visitor taps while a third-party script is mid-task, waits for it, and then waits again while the handler does too much before touching the screen.

Why sites fail it

• Large JavaScript bundles. A framework, a UI library, a slider, a date picker and a form library, shipped to every page, parsed and executed on the main thread while the visitor is already tapping.
• Third-party tags. Analytics, ads, chat widgets, heat maps, A/B testing tools. Each runs its own code on your main thread. On the sites we audit, third parties account for the majority of long tasks more often than not.
• Heavy event handlers. Doing all the work — fetch, compute, re-render — before updating the screen, so the visitor sees nothing until everything is done.
• Layout thrash. Reading a layout property (offsetHeight) and then writing a style, in a loop, forcing the browser to recalculate layout repeatedly.
• A huge DOM. Pages with several thousand elements make every style and layout pass slow, so even cheap handlers produce slow paints.
• Hydration. Single-page-app frameworks that render HTML on the server and then re-run the whole application in the browser to attach event handlers. Until hydration completes, taps are queued.
• Slow phones. None of the above is visible on a developer's laptop. On a mid-range Android, JavaScript runs two to four times slower, and the same handler crosses the 200 ms line.

How to find the culprits

Start from the field, then reproduce in the lab.

1. Field data by page group. PageSpeed Insights shows CrUX INP for the URL and the origin; Search Console's Core Web Vitals report groups failing URLs by template. This tells you which pages, not why.
2. Attribution in the field. The web-vitals library's attribution build reports, for each visitor's worst interaction, the element that was interacted with, the event type, and how the time split across the three phases. Send it to analytics. Within a week you will know it is the "add to cart" button on product pages, with 300 ms of input delay.
3. Reproduce in DevTools. Open the Performance panel, enable 4× or 6× CPU throttling, record, and perform the interaction. Look for long tasks (red-flagged blocks over 50 ms) before and during the interaction, and read the call stack to see whose code it is.
4. Long Animation Frames API. In supporting browsers, PerformanceObserver with type long-animation-frame reports which scripts ran during slow frames — including third parties — with far less effort than manual tracing.

The fixes, in the order they pay off

1. Remove or defer third-party scripts

Inventory every tag with its main-thread cost. Delete what nobody uses (there is always something). Load the rest after the page is interactive, or on user intent — the chat widget when the button is hovered, not on page load. This single step takes many sites from poor to good.

2. Give feedback before doing the work

When a button is tapped, update the screen first — a pressed state, a spinner, an optimistic change — and then do the fetch or computation. INP measures time to the next paint, so a handler that paints immediately and continues working passes even if the work takes a while. Structurally: handle the event, change a class, then setTimeout(work, 0) or await scheduler.yield() before the heavy part.

3. Break up long tasks

Any task over 50 ms blocks the thread from responding. Split loops and initialisation into chunks that yield back to the browser between them, using scheduler.yield() where available or setTimeout as a fallback. Prioritise anything the user is waiting on over anything they are not.

4. Ship less JavaScript

Remove libraries used for one function, tree-shake the bundle, code-split so each page loads only what it uses, and render static content as HTML rather than as a component that hydrates. A marketing site rarely needs a framework at all; where it does, islands or partial hydration limit the damage.

5. Avoid layout thrash and shrink the DOM

Batch reads and writes, animate with transform and opacity instead of layout properties, and use content-visibility: auto on long off-screen sections. Audit templates that generate thousands of nodes — mega-menus, infinite carousels, hidden tab panels full of images.

6. Debounce and throttle input handlers

Search-as-you-type, scroll-linked effects and resize handlers should not run their full logic on every event. Debounce the expensive part; keep the visual feedback instant.

Platform notes

WordPress: the usual cause is plugins loading scripts site-wide — sliders, page-builder runtimes, form libraries, popups. Dequeue on pages that do not use them; replace the heaviest with lighter equivalents; delay third parties. Shopify: apps inject scripts into every page; audit the app list first, then the theme's own JavaScript. Single-page apps: measure hydration time on a throttled device and move toward server-rendered HTML with selective interactivity. In every case the fix is measured on a real mid-range phone, not a laptop.

Verifying the improvement

Lab tests show the change immediately. Field data updates daily but is judged over 28 days, so Search Console's report reflects the full effect three to five weeks after the fixes ship. Keep the attribution events flowing to analytics so you can see the 75th percentile move week by week rather than waiting for the badge to change colour.

INP is not a loading metric; it is a responsiveness metric. It is failed by the JavaScript you ship and the third parties you invite, and it is fixed by shipping less, yielding more, and painting before you compute.

If your Search Console shows INP in amber or red and you would rather have the causes found and fixed than learn the Performance panel, that is exactly the scope of our website speed optimization service — audit from the field data, fix in priority order, verify 28 days later. And if you want the business case first, here is the maths on speed and conversion.