INP is harder to optimise than FID because it captures every interaction, not just the first. A page that loads fast can still fail INP if a JavaScript event handler blocks the main thread for 300ms when a user opens a dropdown. The fix is almost always about reducing long tasks on the main thread — either by deferring work, breaking it into smaller chunks, or moving it off-thread entirely.
Key Takeaways
- Good INP: under 200ms · Needs Improvement: 200–500ms · Poor: over 500ms
- INP measures input delay + processing time + presentation delay — the total from click/tap/keypress to the next frame painted
- Long JavaScript tasks (over 50ms) on the main thread are the primary cause of high INP
- Third-party scripts — tag managers, chat widgets, consent popups — are the most common culprit on publisher and ecommerce sites
- Diagnose with Chrome DevTools Performance panel → Interactions, or PageSpeed Insights → INP breakdown
What INP Measures — The Three Components
An INP interaction has three phases:
Input delay — the time between when the user interacts (click, tap, keypress) and when the browser begins processing the event handler. Input delay is caused by other JavaScript tasks running on the main thread at the moment of the interaction — the browser can't start your event handler until those tasks finish.
Processing time — the time spent executing the event handler itself. Long, synchronous JavaScript in an event handler (DOM manipulation, calculations, state updates) increases this.
Presentation delay — the time between the event handler finishing and the browser actually painting the visual change. Complex layout recalculations or large numbers of DOM nodes can increase this.
INP = the 98th percentile of all interaction durations during the page session. It's not just the worst interaction — it's the worst interaction that real users in the 98th percentile experience. A very rare 2% of interactions are excluded to prevent outliers from dominating.
INP vs FID — What Changed
| Metric | What it measured | When |
|---|---|---|
| FID (retired) | Delay from first user input to browser's first response | First interaction only |
| INP (current) | Full duration from input to visual update | Every interaction during the full page session |
FID was easy to pass — a page that loaded fast rarely had a bad first FID even if subsequent interactions were slow. INP is harder: it catches slow event handlers anywhere on the page — accordions, tabs, search autocomplete, add-to-cart buttons — not just the page load phase.
Common Causes of High INP
Long Tasks Blocking the Main Thread
JavaScript is single-threaded. A long task — any synchronous block of code that runs for over 50ms — prevents the browser from responding to user input. Input delay accumulates for every millisecond a long task runs while the user is trying to interact.
Common sources of long tasks:
- Large JavaScript bundles parsed and executed on load (especially on mobile CPUs)
- Synchronous DOM manipulation in event handlers (querying and updating hundreds of DOM nodes)
- JSON parsing of large API responses on the main thread
- Third-party scripts running at interaction time (analytics, tag managers, CMP cookie banners)
Third-Party Scripts
On content and ecommerce sites, third-party scripts are the most common INP killer. Tag managers, consent popups, live chat widgets, and affiliate tracking scripts run JavaScript in response to user events. A consent CMP that executes 400ms of script on every click fails INP globally, regardless of how clean your own code is.
Render-Blocking Layouts After Interaction
If clicking a button triggers a complex layout recalculation — showing/hiding large DOM sections, reflowing text with variable-length content, or animating elements with properties that force layout — the presentation delay phase increases. Prefer animating transform and opacity (handled by the compositor thread, no layout) over animating height, top, or width (forces main-thread layout).
How to Diagnose INP
PageSpeed Insights — Real User Data
PageSpeed Insights shows field INP from the Chrome User Experience Report (real users). The "INP" row shows your 75th percentile interaction latency and which threshold band you're in. Scroll to "Diagnose performance issues" for the INP breakdown showing which interaction contributed.
Chrome DevTools Performance Panel
Record a Performance trace while reproducing the slow interaction. Look for:
- Long tasks (red flag bar at the top of the main thread lane) during the interaction
- The "Interactions" track — shows INP interactions and their full duration
- Which functions run inside the long task — these are the code to optimise
Page Speed Inspector
The Page Speed Inspector checks third-party script load on the page and flags render-blocking resources — the same scripts that cause both slow LCP and high INP input delay. A high third-party script count is a reliable indicator of INP risk.
Fixes by INP Phase
Reducing input delay: Break long tasks into smaller chunks using setTimeout(fn, 0) or scheduler.postTask() to yield control back to the browser. Use requestIdleCallback for non-urgent background work so it doesn't run when the user is interacting.
Reducing processing time: Debounce or throttle expensive event handlers. Avoid querying the full DOM on every keypress in a search input. Cache DOM references instead of re-querying. Move heavy computation off the main thread with Web Workers.
Reducing presentation delay: Minimise DOM nodes in the interaction's scope. Use CSS contain to isolate layout recalculations to a subtree. Avoid forced synchronous layouts (reading layout properties like offsetWidth immediately after writing DOM changes).
Check Your Page for Third-Party Script Load and Render-Blocking Resources
Free, no signup. The Page Speed Inspector reveals every third-party script loaded on the page, render-blocking resources, and timing metrics — the three variables most strongly correlated with high INP scores.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.