INP Troubleshooting: A Practical Checklist for Long Tasks, Slow Event Handlers, and Third-Party Scripts

Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024, and many sites still struggle with it. INP measures the full round-trip of an interaction—from user input through processing to the next visual update. When INP fails, something in that chain is taking too long. This checklist walks through the most common causes in priority order.

Understanding what INP actually measures

INP captures the worst interaction responsiveness across a page visit, reported at the 98th percentile. Unlike First Input Delay which only measured input delay, INP includes three phases: input delay (time waiting for the main thread), processing time (event handler execution), and presentation delay (time to render the visual update).

This means INP can fail because of any phase. A long task blocking the main thread causes input delay. Expensive event handler logic causes processing time issues. Complex rendering after the handler causes presentation delay. Fixing INP requires identifying which phase dominates.

The threshold is 200ms. Interactions completing within 200ms feel responsive. Between 200-500ms feels sluggish. Over 500ms feels broken. Most INP failures fall in the 200-500ms range—not catastrophically slow, but noticeably unresponsive.

Step 1: Identify which interactions fail

Not all interactions contribute equally to INP. Use Chrome DevTools Performance panel to record user interactions and identify which ones are slowest. Click buttons, open menus, toggle filters, submit forms—the interactions your visitors actually perform.

Check your field data for INP attribution if available. The Web Vitals JavaScript library can log which elements and interaction types contribute to poor INP. This real-user data reveals problems lab testing might miss.

Focus on the worst interactions first. Fixing the single slowest interaction often improves INP significantly because INP reports near-worst-case (98th percentile). One problematic interaction pattern can drag down the entire page’s INP score.

Step 2: Check for long tasks blocking the main thread

Long tasks (over 50ms) are the most common INP culprit. They block the main thread, preventing the browser from responding to user input. Even if your event handler is fast, a long task running when the user clicks creates input delay.

Open DevTools Performance panel, record a session, and look for long yellow (scripting) blocks in the main thread. These represent JavaScript execution blocking other work. The longer the block, the worse the potential input delay.

Common sources of long tasks include: large JavaScript bundles executing during page load, complex DOM manipulation, synchronous layout calculations, and garbage collection pauses. Third-party scripts frequently contribute long tasks that compete with your interaction handlers.

Break long tasks into smaller chunks using setTimeout, requestAnimationFrame, or the scheduler.yield() API. This allows the browser to process user input between chunks rather than waiting for the entire task to complete.

Step 3: Audit event handler performance

If input delay isn’t the issue, the event handler itself may be too slow. Measure how long your click handlers, input handlers, and other event callbacks take to execute.

Expensive operations inside handlers include: DOM queries across large trees, complex calculations, state management updates that trigger cascading re-renders, and synchronous network-dependent operations. Each millisecond in the handler directly increases INP.

Move non-visual work out of the interaction path. If a click handler needs to update analytics, save data, and update the UI, prioritise the visual update. Defer analytics and data persistence using requestIdleCallback or microtask queues. The user sees a responsive interface while background work completes asynchronously.

Avoid forced synchronous layouts inside handlers. Reading layout properties (like offsetHeight or getBoundingClientRect) after making DOM changes forces the browser to calculate layout immediately. Batch DOM reads before writes, or defer layout reads to the next frame.

Step 4: Examine third-party script interference

Third-party scripts—analytics, advertising, chat widgets, social embeds—frequently cause INP problems without appearing in your own code. They run on the same main thread and compete for processing time.

Audit third-party script impact by recording Performance profiles with and without third-party scripts loaded. The difference reveals how much main thread time they consume. Some analytics scripts add 100-200ms of blocking time per page.

Defer non-critical third-party scripts. Load them after the page becomes interactive rather than during initial page load. Use async or defer attributes, or load scripts programmatically after a delay or user interaction.

Consider removing scripts that provide marginal value relative to their performance cost. Every third-party script is a tradeoff. If a social sharing widget adds 150ms to interaction times but generates minimal engagement, removing it improves experience for all visitors.

Use web workers for heavy third-party processing where possible. Some analytics libraries offer web worker variants that execute off the main thread. This eliminates their contribution to main thread blocking entirely.

Step 5: Check presentation delay

After the event handler completes, the browser must render the visual update. Complex rendering can add significant time to the interaction. This presentation delay is often overlooked.

Large DOM updates trigger expensive rendering. If a click handler updates hundreds of DOM elements, the browser needs time to recalculate styles, layout, and paint. Consider updating only visible elements and deferring off-screen updates.

CSS complexity affects rendering speed. Deeply nested selectors, expensive properties like filter or backdrop-filter, and large numbers of affected elements slow style recalculation. Simplify CSS where possible, especially for elements that change during interactions.

Animations triggered by interactions should use compositor-friendly properties: transform and opacity. These animate without triggering layout or paint. Properties like width, height, top, left trigger layout recalculation on every frame, creating jank during interaction transitions.

Step 6: Test on representative devices

INP problems often manifest on mid-range and low-end devices but not on development machines. Your fast laptop processes JavaScript quickly; your visitors’ three-year-old phones do not.

Use DevTools CPU throttling to simulate slower devices. 4x or 6x slowdown reveals INP issues invisible at full speed. This approximates how your site performs on budget Android devices—a significant portion of global web traffic.

Test on actual devices when possible. Real device testing catches issues throttled simulation misses: thermal throttling, memory pressure, background processes competing for CPU. Emulation improves but doesn’t perfectly replicate real device constraints.

Chrome’s Web Vitals overlay shows live INP measurements as you interact. Enable it in DevTools to see immediate feedback on interaction responsiveness during testing.

The systematic approach

Work through these steps in order. Most INP problems resolve at steps 2-4: long tasks, slow handlers, or third-party interference. Presentation delay (step 5) is less common but important for complex interactive pages.

After each fix, measure again. INP improvements are often incremental. Fixing one 300ms long task might improve INP from 350ms to 250ms. Fixing the event handler might drop it to 180ms. Each improvement compounds.

Monitor field data after deploying fixes. Lab improvements should translate to field improvements, but verify. Real-user devices and interaction patterns may reveal issues lab testing missed. The 28-day rolling window in CrUX means patience is required—but the trend should be visible within weeks.

INP optimisation isn’t a one-time project. New features, updated libraries, and additional third-party scripts can regress performance. Regular monitoring catches regressions before they impact Core Web Vitals assessments. Our performance service includes ongoing monitoring and prioritised action plans to keep INP within passing thresholds.