Fixing Interaction to Next Paint (INP): Why Your Clicks Feel Sluggish & How to Fix Them

01 / The Anatomy of an Interaction: The 3 Phases of INP

To fix poor INP, you must understand that INP is not a single timer; it is the sum of three distinct chronological phases:

1. Input Delay: The time between when the user physically touches the screen and when the browser's main thread is free to start executing your event handler. If a third-party tracking script is currently executing a 200ms Long Task, the user's tap sits waiting in the browser queue.
2. Processing Time: The synchronous time taken by your JavaScript event callback to execute (e.g. state recalculations, filtering 2,000 array items, complex DOM creation).
3. Presentation Delay: The time required for the browser engine to recalculate style layout, execute composite painting, and present the newly rendered frame onto the physical screen pixels.

Google considers an INP below 200ms as passing ("Good"). Anything above 500ms triggers severe ranking penalties in Google mobile search.

02 / How to Measure & Isolate INP with Chrome DevTools

You can reproduce and isolate your site's worst INP interactions in less than 5 minutes using the Chrome DevTools Performance panel:

1. Open an Incognito browser window, open DevTools (F12), and navigate to the Performance tab.
2. Click the gear icon, set CPU throttling to 4x Slowdown, and click Record.
3. Interact with your website like an impatient mobile user: rapidly open and close the mobile navigation drawer, tap an accordion, type into a search input, and click "Add to Cart".
4. Click Stop and look at the new Interactions track in the timeline. Red bars highlight any interaction that exceeded 200ms.
5. Click on the red interaction bar to inspect the Summary. Chrome will show you the exact line of JavaScript code and script file responsible for locking the thread.

03 / Breaking Up Long Tasks with scheduler.yield()

The single most powerful architectural solution to INP is main thread task yielding.

In standard synchronous JavaScript, if you have a task that takes 180ms to process, the browser cannot paint any visual feedback (like a loading spinner, active tab highlight, or button depressed state) until all 180ms of execution finish. The user thinks the app has frozen and rage-taps the screen.

By inserting await scheduler.yield() into heavy computational loops, you tell the JavaScript engine: "Pause here, let the browser paint the user's visual feedback and process any pending touch inputs, then resume my task on the next micro-task cycle."

04 / Production Code: Asynchronous Task Yielding Helper

Here is the robust, production-tested JavaScript yield helper with fallback polyfill that I deploy on enterprise client applications:

/**
 * Yields execution back to the browser main thread to allow
 * UI painting and pending input events to process immediately.
 */
export async function yieldToMain(): Promise<void> {
  // Check for native scheduler.yield support (Chrome 129+, modern Chromium)
  if ('scheduler' in window && 'yield' in (window as any).scheduler) {
    return await (window as any).scheduler.yield();
  }

  // Fallback 1: MessageChannel macro-task yielding (sub-1ms resolution)
  if (typeof MessageChannel !== 'undefined') {
    return new Promise((resolve) => {
      const channel = new MessageChannel();
      channel.port1.onmessage = () => resolve();
      channel.port2.postMessage(null);
    });
  }

  // Fallback 2: Standard setTimeout macro-task
  return new Promise((resolve) => setTimeout(resolve, 0));
}

/**
 * Example usage: Processing large datasets without freezing user taps
 */
export async function processHeavyLeadData(items: Array<any>) {
  let lastYieldTime = performance.now();

  for (let i = 0; i < items.length; i++) {
    // Process single item chunk
    executeBusinessLogic(items[i]);

    // If 16ms have elapsed (one 60fps frame budget), yield back to browser
    if (performance.now() - lastYieldTime > 16) {
      await yieldToMain();
      lastYieldTime = performance.now();
    }
  }
}

05 / Before vs After INP Optimization Benchmarks

Here are the verified real-world Core Web Vitals telemetry results from a high-traffic e-commerce portal after refactoring event handlers with task yielding:

06 / Framework-Specific Fixes (React 19 & WordPress)

If you build with React, wrap non-urgent state updates inside startTransition(() => setState(...)). This tells React that visual feedback takes priority, allowing urgent user keystrokes to interrupt background DOM rendering.

If you are on WordPress, high INP is almost always caused by unoptimized slider scripts (Slick, Swiper), live chat widgets (Tidio, Intercom), and tag managers executing hundreds of analytics trackers synchronously on click events. Defer tracking pings using navigator.sendBeacon() to keep the main thread unblocked.

Explore my complete engineering services on my Custom Code Web Development page.

07 / Technical FAQs

Written by Rohan Shahzad

Full-Stack Web Developer & Core Web Vitals Performance Engineer. Solving complex frontend bottlenecks, main-thread JavaScript latency, and responsive mobile architecture.