INP Optimization: How to Fix Interaction to Next Paint

Interaction to Next Paint (INP) measures how quickly a page responds when someone clicks, taps or presses a key. A good INP is 200 milliseconds or less at the 75th percentile of page loads recorded in the field; above 200 ms and up to 500 ms needs improvement, and anything above 500 ms is poor (web.dev). It is the Core Web Vital teams understand least, and JavaScript-heavy sites are the ones it catches out.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and the change mattered. FID measured only the delay before the browser started processing your first interaction, a low bar that most sites cleared without trying. INP measures the full latency of interactions throughout the visit, from tap to the next visual update. It is a much more honest measure of how responsive a page feels.

What INP actually measures

INP observes the clicks, taps and key presses during a visit (hovering and scrolling don’t count) and reports the longest interaction, ignoring outliers: one highest interaction is set aside for every 50. Each interaction has three parts:

• Input delay: the time before the event handler can start, usually because the main thread is busy with something else.
• Processing duration: how long your event handlers take to run.
• Presentation delay: the time to render the next frame after the handlers finish.

Together they are what the user perceives as “did the page respond.” A high INP feels like lag: you tap, and nothing happens for a beat. That hesitation is what the metric captures, and it tracks closely with how much work your frontend asks a mid-range phone to do.

Why sites fail INP

The root cause is usually the same: too much JavaScript running on the main thread.

Long tasks block the main thread

The browser runs your JavaScript on a single main thread, and while a long task runs, the page can’t respond to input. A task that takes 300 ms means any tap during that window waits until it finishes. Heavy frameworks, large bundles and unoptimized application code create long tasks, and long tasks are the direct cause of poor input delay.

Third-party scripts

Tag managers, analytics, chat widgets, A/B testing tools and ad scripts run on the same main thread as your own code. One poorly behaved third-party script can dominate INP across the entire site, and because it loads from someone else’s server, it never shows up in your own code review. Auditing third-party weight is often the best-value INP work available.

Expensive event handlers and layout thrashing

Handlers that do heavy synchronous work (large DOM updates, layout reads and writes interleaved, expensive state recalculation) push up processing and presentation time. React and other framework re-renders that touch large parts of the tree on every interaction are a common culprit.

How to fix INP

Ship less JavaScript

The most durable fix is to send less code in the first place. This is why architecture matters: a site that hydrates an entire React tree pays an INP tax that a mostly static site never incurs. Frameworks that ship almost no JavaScript by default, and hydrate only the interactive islands, start from a structurally better position. That is a large part of why we build content sites the way we do in our website development practice.

Break up long tasks

Where you do run JavaScript, split long tasks into smaller chunks so the browser can respond to input between them. Yield to the main thread (with scheduler.yield() where the browser supports it, or by deferring non-urgent work) and move heavy computation off the critical path. The goal is that no single task holds the thread long enough to delay an interaction.

Defer and tame third parties

Load non-critical third-party scripts late, after the page is interactive, and question every tag. Many analytics and marketing scripts can be deferred, loaded on interaction or loaded more efficiently without losing the data you actually use. On WordPress, plugin sprawl is a common source of third-party weight, which is why we treat plugin discipline as core to WordPress engineering rather than an afterthought.

Optimize what runs on interaction

Keep event handlers lean. Debounce expensive work, avoid layout thrashing, and in framework apps narrow the scope of re-renders so a single click doesn’t recompute the whole page. Render the visual feedback first (the state the user expects to see), then do the heavier work.

How to measure it correctly

INP is a field metric: it reflects real users on real devices, not a single lab run. Use Chrome User Experience Report (CrUX) data and the tools that read it (PageSpeed Insights and Search Console’s Core Web Vitals report) to see your actual 75th-percentile INP. Lighthouse’s default page-load test can’t measure INP, because nobody interacts with the page; it reports Total Blocking Time as a lab proxy, and its timespan mode can record interactions you perform. Fix in the lab, verify in the field.

A useful debugging loop: reproduce the slow interaction in the Chrome DevTools Performance panel, find the long task in the flame chart, identify the script responsible and attack that specific task. INP problems usually concentrate in a handful of interactions rather than spreading evenly. Find the worst one and you have found most of the score.

The bottom line

INP rewards sites that respect the main thread and punishes sites that drown it in JavaScript. The reliable path to a good score is structural: ship less code, defer what you can and keep interactions cheap. It is the same discipline that produces good Core Web Vitals at scale. If your site fails INP and the usual caching-and-plugins advice hasn’t moved it, the problem is the JavaScript execution model, which is what our performance engineering work is built to fix.