INP problems explained: causes of slow interactions and how to fix them
Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a page responds to clicks, taps and key presses. An INP above 200 ms feels sluggish; above 500 ms it feels broken.
Almost every bad INP score comes down to one of a handful of root causes. Each guide below explains one cause: how to recognise it, why it happens, and how to fix it — with code.
Root causes
A long-running event handler blocks the main thread and delays the next paint. How to find heavy handlers and break them up with scheduler.yield() or Web Workers.
Layout thrashing: repeated reflows in one frame and how to stop themAlternating DOM reads and writes force the browser to recalculate layout over and over in a single frame. How to batch reads and writes to fix INP.
Forced synchronous layout: reading geometry after writing to the DOMReading offsetWidth or getBoundingClientRect right after changing the DOM forces the browser to recalculate layout inside your JS task. How to detect and fix it.
Main thread blocked: high input delay before your handler even runsWhen the main thread is busy with another long task, clicks wait in a queue before your handler starts. How to find and split the blocking task to fix INP input delay.
Third-party scripts blocking interactions: diagnosing and containing themAnalytics, ads and chat widgets run long tasks on your main thread and ruin INP. How to attribute long tasks to third parties and contain them with async, defer or a worker.
React re-render cascade: when one click re-renders the whole treeA state update high in the React tree re-renders hundreds of components on every click. How to find render cascades and fix them with memo, useCallback and useTransition.