Troubleshooting guide · performance · Published 2026-08-16 · 4 min read
Debug INP in DevTools
Debug INP with Chrome DevTools: trace a click, read interaction timing, isolate the long task behind input delay, and the fixes for each source.
- ·Trace an interaction
- ·Read input delay
- ·Fix the task
INP is an interaction metric, so trace the interaction
INP (Interaction to Next Paint) measures the worst interaction's full timeline: input delay while the main thread is busy, plus handler execution and the repaint. Debugging it in DevTools means reproducing the actual interaction, not reloading the page.
The Performance panel home in current Chrome shows live local metrics including INP once you interact, and the recording view carries an Interactions track. Open DevTools > Performance, check the Interactions row, record, then click, tap, or type on the page. The interaction shows in the summary with its Input Delay, Processing Duration, and Presentation Delay breakdown, plus the associated long task.
Interaction (click)
Input Delay 34 ms
Processing Duration 420 ms <-- main thread spent 420ms in a task
Presentation Delay 8 msINP is the sum of all three legs. It stays under 200 ms only when the whole chain is short; a 420 ms processing duration on one task blows the metric by itself.
The DevTools trace of an interaction
- Open Performance, check the
Interactionsrow, and begin recording. - Perform the exact slow interaction (click a tab, open the mobile menu, submit a filter).
- In the Main thread track, find the task that contains the interaction handler, and note whether it also contains other work (three unrelated handlers batched into one task).
- Expand the
Long Taskssection of the summary: DevTools labels itLong(orange) when the task crosses 50 ms, which is the threshold that inflates INP.
The three fixes mapped to the trace
| Trace finding | Root cause | Fix |
|---|---|---|
Large red Task containing the click handler | The handler itself does layout, network, or big work | Split the work, move it off the main thread, or pre-compute |
| Long task before the interaction's input delay | Main thread was busy when the user clicked | Schedule work away from input, break the task into chunks |
| Presentation delay high after handler | Browser reflow/repaint is heavy (animations, layout reads) | Reduce layout, use transform/opacity, batch writes |
The INP optimisation article covers each of these families in a fix order; the debugging skill is naming which family your trace hits.
The field-lab loop
A lab trace proves a handler is 420 ms, but INP as a metric is the field's 75th percentile of the worst interactions, which is what the Core Web Vitals report buckets. The reliable loop:
- Reproduce the slow interaction in DevTools, fix the measured task.
- Add the web-vitals library (or the long task attribution API) to capture real INP on a staging site.
- Compare
INPin the field with the lab trace: if the field is the same value as the trace, the fix holds; if the field is worse, the field has a different interaction (a third-party script waiting on the main thread) that the lab run with a clean network did not expose.
What to leave out of the main thread
The single most common INP bug is a module that runs timing code on every interaction (a size observer, a picker, a rich text editor) and does it on the main thread. If the trace shows the same interaction handler taking geometry reads or layout writes on every click, the fix is to cache the measurement, or move the widget off the main thread, before the interaction starts. When the interaction is a modal or a search box, defer loading its script until the trigger is opened, which the bundle reduction article frames as the broad strategy.
Putting a number on it: an interaction that would pass at 150 ms fails at 450 ms. The trace shows it is one task, named by the DevTools Main track, so the fix is confirmably small. The audit procedure guide keeps INP field and lab in the same weekly discipline.