INP (Interaction to Next Paint)
INP (Interaction to Next Paint) is a Core Web Vital metric introduced by Google in March 2024 to replace First Input Delay (FID) as the interactivity measure in the page experience signal; INP is measured from when a user interacts with an element (mouse click, touch, key press) to when the browser completes rendering the next visual update (paint) in response to that interaction; For WordPress-based content publishers, poor INP is most commonly caused by the cumulative weight of third-party scripts: Google Analytics, Google Ad Manager, affiliate tracking pixels, and push notification SDKs all run JavaScript that competes for the main thread
INP (Interaction to Next Paint) is a Core Web Vital metric introduced by Google in March 2024 to replace First Input Delay (FID) as the interactivity measure in the page experience signal. While FID measured only the delay before the browser could begin processing the very first user interaction, INP measures the latency of all interactions (clicks, taps, keyboard inputs) throughout the entire page visit, reporting the worst-case interaction delay. Google’s Good threshold for INP is under 200 milliseconds; 200-500ms is Needs Improvement; above 500ms is Poor.
How it works
INP is measured from when a user interacts with an element (mouse click, touch, key press) to when the browser completes rendering the next visual update (paint) in response to that interaction. Long INP scores are caused by long JavaScript tasks blocking the main thread, preventing the browser from processing user input promptly. Common causes include heavy third-party scripts (analytics, ads, chat widgets) that run on the main thread, large React or Vue component re-renders triggered by user actions, and synchronous operations during event handlers that delay visual feedback.
Key facts
- Worst interaction reported: INP reflects the worst-case interaction delay across the session (excluding outliers), making it sensitive to any single slow interaction on the page.
- Main thread blocking: Long tasks (JavaScript running more than 50ms without yielding) are the primary cause of poor INP; breaking long tasks with yielding patterns (setTimeout, scheduler.yield) is the primary fix.
- Third-party impact: Third-party tag scripts from analytics, ad networks, and marketing tools often account for 40-70% of main thread blocking on publisher sites.
For builders
For WordPress-based content publishers, poor INP is most commonly caused by the cumulative weight of third-party scripts: Google Analytics, Google Ad Manager, affiliate tracking pixels, and push notification SDKs all run JavaScript that competes for the main thread. Auditing and removing unused third-party tags, loading non-critical scripts asynchronously, and deferring tag execution until after the first user interaction are the highest-leverage INP improvements. Tools like WebPageTest and Chrome DevTools Performance panel with the ‘long tasks’ overlay help identify the specific scripts causing main thread blocking.
Sources
- Google. Web Vitals documentation, including Core Web Vitals. web.dev
- Google. Page experience and Core Web Vitals as ranking signals. developers.google.com
- W3C. Performance Timeline specification. w3.org
- Chromium. Speed and performance metrics documentation. chromium.googlesource.com
- HTTP Archive. Web performance public dataset. httparchive.org