Optimising for INP (Interaction to Next Paint): The New Core Web Vital Guide for 2026

Google has officially replaced First Input Delay (FID) with Interaction to Next Paint (INP) as a core ranking signal. While FID measured only the delay before the browser began processing a user’s initial click, INP assesses the responsiveness of every single interaction—clicks, taps, and key presses—throughout the entire user session. If clicking a menu, opening a filter, or typing in a form feels sluggish on mobile devices, your INP score will drop into the red.

1. Understanding the INP Performance Thresholds

Google evaluates real-world field data gathered from the Chrome User Experience Report (CrUX) at the 75th percentile:

• Good (Green): Less than or equal to 200 milliseconds.
• Needs Improvement (Amber): Between 200ms and 500ms.
• Poor (Red): Exceeding 500 milliseconds.

2. Prime Culprits Behind Sluggish INP

The dominant cause of poor INP is main-thread blockage by monolithic JavaScript tasks. When a user clicks a button, the browser cannot render visual feedback until long-running scripts, heavy DOM manipulations, or unoptimized third-party tracking tags finish executing. Layout thrashing—repeatedly reading and writing DOM geometry properties in rapid succession—also forces costly reflows.

3. Practical Code Fixes to Modernize INP

Implement these performance best practices across your front-end code:

1. Break up long tasks using modern APIs like scheduler.yield() or setTimeout() so the browser can immediately repaint user feedback before resuming background computation.
2. Debounce real-time search inputs and filter recalculations to avoid triggering execution on every keystroke.
3. Audit and purge redundant third-party marketing tags, heatmaps, and chat widgets that hijack the main thread during user scrolling.