Stop Guessing INP: Fix Interactions Without These Common Errors

Interaction to Next Paint (INP) measures how quickly a page responds to user interactions like clicks, taps, and key presses. A poor INP frustrates users and can hurt your search rankings. Yet many teams approach optimization by guessing at causes—tweaking code without a clear diagnosis. This guide explains the real mechanisms behind INP delays and the most common mistakes in fixing them. We provide a systematic, evidence-based process so you can improve INP with confidence.

Why Guessing Fails: The Real Cost of INP Misdiagnosis

INP captures the entire interaction lifecycle: input delay, processing time, and presentation delay. Guessing at which phase is slow leads to wasted effort. For example, a team might optimize JavaScript execution when the real bottleneck is a long frame caused by layout thrashing. Without isolating the culprit, you risk making changes that don't move the metric.

The Three Phases of an Interaction

Every interaction goes through three phases: input delay (time from user action until event handlers begin), processing time (time spent in event handlers), and presentation delay (time until the next paint shows the result). INP is the worst-case interaction across the page visit, typically the 75th percentile. Misdiagnosis often occurs because developers focus on only one phase—usually processing—while ignoring input delay caused by long tasks from unrelated scripts.

Common Misdiagnosis Patterns

One frequent error is assuming that all interactions are equally slow. In practice, INP is dominated by the slowest interaction. Teams may optimize a fast interaction and miss the real problem. Another pattern is blaming third-party scripts without evidence. While third-party code can cause long tasks, many INP issues stem from first-party event handlers that are unnecessarily complex. A composite scenario: a news site saw INP over 300 ms. The team optimized their main button click handler, reducing processing time from 80 ms to 30 ms, but INP barely changed. The real issue was a lazy-loaded analytics script that caused a 200 ms input delay on the first interaction. They had guessed wrong.

How INP Really Works: The Mechanisms You Must Understand

INP is fundamentally about the browser's event loop. When a user interacts, the browser must finish any current task before starting the interaction. This means long tasks—any task over 50 ms—are the primary cause of input delay. Processing time depends on how long your event handlers run, and presentation delay depends on rendering work triggered by those handlers.

Long Tasks and Input Delay

Input delay is the time between the user's action and when the browser can begin processing the event. If the main thread is busy with a long task—such as parsing a large script or recalculating styles—the interaction waits. Reducing long tasks is often the highest-impact change for INP. Techniques include code splitting, deferring non-critical scripts, and using requestIdleCallback for background work.

Processing Time: What Happens Inside Event Handlers

Once the event handler starts, its execution time adds directly to INP. Some handlers are unavoidably complex, like those that update a large list or perform animations. However, many handlers do unnecessary work: querying the DOM repeatedly, using getBoundingClientRect in a loop, or triggering forced layouts. A key insight is that you can often restructure handlers to reduce processing time without changing functionality. For example, batch DOM reads and writes to avoid layout thrashing.

Presentation Delay: The Hidden Culprit

After event handlers finish, the browser must render changes. If your handlers trigger style recalculations or layout changes, that work adds to presentation delay. This phase is often overlooked because it appears in DevTools as part of the interaction but is not directly under the event handler's timing. Reducing forced layouts and using transform and opacity for animations (which are composited on the GPU) can cut presentation delay significantly.

A Systematic Process for Diagnosing and Fixing INP

Instead of guessing, follow a repeatable process: measure, isolate, diagnose, optimize, and verify. This ensures you address the real bottleneck.

Step 1: Measure INP with Lab and Field Data

Start with field data from the Chrome User Experience Report (CrUX) or Real User Monitoring (RUM) to understand real-world INP. Then use lab tools like Lighthouse or the Performance panel in DevTools to reproduce slow interactions. Record a trace of the slowest interaction you can find. Look for the interaction's duration and break it into input delay, processing, and presentation.

Step 2: Isolate the Slow Interaction

Identify which specific element and event (e.g., click on a button) causes the worst INP. In DevTools, enable the "Web Vitals" overlay or use the Performance panel with the "Interactions" track. Click around the page and note which interaction has the highest duration. Focus on that one first.

Step 3: Diagnose the Phase Causing the Delay

In the Performance panel, examine the interaction's timeline. If input delay is high, look for long tasks before the interaction. If processing time is high, examine the event handler's script duration and look for forced layouts or expensive DOM operations. If presentation delay is high, inspect layout and paint events after the handler. Use the "Bottom-Up" or "Call Tree" tabs to find the most expensive functions.

Step 4: Optimize Based on Diagnosis

• High input delay: Break up long tasks with setTimeout or requestAnimationFrame. Defer non-critical scripts. Use web workers for heavy computation.
• High processing time: Simplify event handlers. Avoid synchronous layout queries. Use passive event listeners for scroll and touch events. Consider debouncing or throttling.
• High presentation delay: Minimize DOM changes. Use will-change wisely. Batch style changes. Avoid changing layout properties in handlers that trigger repaint.

Step 5: Verify the Fix

After making changes, rerun the same interaction trace. Compare the before and after durations. Check that INP improved in lab tests and, after deployment, in field data. Be aware that field data may take days to reflect improvements.

Tools and Techniques for Reliable INP Optimization

Several tools can help you measure and diagnose INP without guesswork. Each has strengths and limitations.

Browser DevTools (Performance Panel)

Chrome DevTools provides the most detailed view of interactions. You can record a trace and see every task, event handler, and paint. The "Interactions" track highlights each interaction with its duration. However, the trace can be overwhelming. Focus on the interaction you identified as slow. Use the "Summary" tab to see the breakdown of input delay, processing, and presentation. A common mistake is looking at the wrong interaction—make sure you select the slowest one.

Lighthouse

Lighthouse simulates a slow device and provides an INP score along with actionable diagnostics. It can identify long tasks and suggest code splitting. However, it uses a synthetic test with a limited set of interactions (typically a click on a button). It may not capture the worst interaction on your page. Use Lighthouse as a starting point, not a definitive diagnosis.

Web Vitals Library and RUM

The web-vitals library lets you track INP in production with real users. You can report the value along with metadata like the element that triggered it. This is the most reliable way to know your true INP. Many RUM providers (e.g., SpeedCurve, Datadog) offer dashboards that break down INP by interaction type. Use this data to prioritize which interactions to optimize.

Comparison of Approaches

Common Mistakes and How to Avoid Them

Even with good tools, teams make recurring mistakes. Here are the most common and how to avoid them.

Mistake 1: Optimizing the Wrong Interaction

As mentioned, INP is the worst interaction. Teams often optimize a common interaction that is already fast. Instead, use field data to find the actual worst interaction. In one composite scenario, a team optimized a search autocomplete handler from 150 ms to 50 ms, but their INP remained high because a third-party widget's click handler was taking 400 ms. They were fixing the wrong thing.

Mistake 2: Ignoring Pointer Events and Tap Delays

Mobile interactions often involve pointer events or tap delays. If you only test with mouse clicks, you might miss issues with touch events. Ensure your event listeners are passive where possible (e.g., touchstart, scroll). Also, avoid using click events on mobile if you can use pointerdown to reduce delay.

Mistake 3: Misinterpreting DevTools Data

A common error is looking at the "Total" time of a task and assuming it equals processing time. In reality, the interaction's processing time is only the time spent in event handlers, not the entire task. Also, input delay is not always visible as a separate task; it may be part of a preceding long task. Use the "Interactions" track to see the exact boundaries.

Mistake 4: Over-Optimizing Without Measuring

Some teams rewrite code based on assumptions—for example, moving all scripts to async without checking if they cause input delay. This can introduce new bugs without improving INP. Always measure before and after.

Decision Checklist: When to Use Each Technique

Use this checklist to decide which optimization to apply based on your diagnosis.

If Input Delay Is the Problem

• Identify long tasks before the interaction. Use requestIdleCallback or setTimeout to break them up.
• Defer non-critical scripts with defer or async. Consider lazy-loading below-the-fold content.
• Move heavy computation to a web worker.
• Avoid using document.write or synchronous XHR.

If Processing Time Is the Problem

• Simplify event handlers: remove unnecessary DOM queries, cache results, avoid forced layouts.
• Use passive event listeners for scroll and wheel events.
• Debounce or throttle rapid events like mousemove or resize.
• Split large handlers into smaller functions that yield to the main thread.

If Presentation Delay Is the Problem

• Batch DOM updates: read all values first, then write changes.
• Use transform and opacity for animations instead of top, left, or width.
• Avoid changing layout properties in event handlers that cause repaint.
• Consider using will-change to hint the browser about upcoming changes.

When Not to Use These Techniques

Not every page needs aggressive optimization. If your INP is already under 200 ms for desktop and under 300 ms for mobile, focus on other Core Web Vitals like LCP or CLS. Over-optimizing can add complexity and maintenance burden. Also, if your site is primarily informational with few interactive elements, INP may not be a priority.

Synthesis: A Reliable Path to Better INP

Improving INP does not require guesswork. By understanding the three phases of an interaction, using the right tools, and following a systematic process, you can identify and fix the real bottlenecks. The key takeaways are:

• Always start with field data to find the worst interaction.
• Use DevTools to break down the interaction into input delay, processing, and presentation.
• Optimize based on the phase that is slowest, not on assumptions.
• Verify every change with before-and-after measurements.
• Avoid common mistakes like optimizing the wrong interaction or misreading DevTools.

Next steps: set up RUM with the web-vitals library to track INP in production. Then, manually test the worst interactions on a representative device. Use the checklist above to guide your optimizations. Finally, monitor field data to confirm improvements. With this approach, you can stop guessing and start fixing INP effectively.