High INP: how to diagnose slow interactions and reduce main-thread work

Executive brief

Key takeaways

• INP requires real interactions; Lighthouse cannot reproduce it alone.
• Find which interaction and phase dominate latency.
• Break up long tasks and update only the necessary interface area.
• Provide fast visual feedback without hiding excessive processing.

Interaction to Next Paint measures how long a page takes to present visual feedback after clicks, taps and keyboard input. High INP may happen during loading, search, menu opening, variant selection, cart actions or form completion.

The recommended threshold is 200 milliseconds at the 75th percentile. Because the metric depends on real usage throughout a visit, a test that only loads the page cannot diagnose the full experience.

Understand the three phases

Input delay

This is the time between user input and the start of the event handler. The browser may be busy running JavaScript, a third-party callback, style calculation or another main-thread task.

Processing

This is time spent in handlers and work they trigger. Heavy validation, serialization, loops, filtering, state updates and rerenders can dominate.

Presentation delay

After code runs, the browser still calculates styles, layout and paint. Updating a large DOM area or alternating layout reads and writes delays the next frame.

A diagnosis should identify the dominant phase. “Reduce JavaScript” is a direction, not a cause.

Begin with field data

Public data may show that an origin or page group fails INP but usually cannot identify the slow button. First-party web-vitals instrumentation can record the metric and diagnostic attributes while respecting privacy.

Combine the signal with template, device, journey stage, application version, frequent interactions and nearby errors or abandonment. Do not capture typed text or personal data; identify components and event types.

Reproduce important interactions

List critical actions per template: open navigation, manage consent, use search and filters, select a variant, add to cart, advance checkout, send a form, expand FAQ and open tabs or dialogs.

Record these actions in Chrome Performance on a representative device or with controlled slowdown. Repeat them. The first interaction may initialize work that later interactions avoid.

Find long tasks

Long tasks occupy the main thread and make new input wait. Investigate bundle evaluation, hydration, tag managers, chat widgets, experiments, maps, video players, component libraries, large lists, JSON processing and complex validation.

Breaking a task lets the browser process input and render between pieces. Options include yielding, scheduling non-urgent work and moving appropriate computation to Web Workers.

Reduce initial and late JavaScript

INP is not only a loading metric. Scripts that arrive later still compete with interactions.

Ask whether each component needs hydration, can use HTML and CSS, can load after interaction, can execute on the server, is included on pages where it is unused, duplicates a native browser feature or brings a dependency much larger than its purpose.

Editorial content, simple navigation, native details/summary and browser form features can reduce JavaScript without sacrificing experience.

Update fewer elements

A small click should not render the whole page. Review component boundaries, state selectors and effect dependencies.

Common problems include global context updates on every keystroke, recomputing an entire list for a local change, unstable keys, chained effects, layout reads after each write and large tables without appropriate virtualization.

Measure before applying memoization everywhere. Caching also carries cost and complexity.

Control high-frequency events

input, scroll, pointermove and resize may fire frequently. Use throttling for continuous work, debouncing when the action can wait, requestAnimationFrame for visual work, passive listeners where compatible and cancellation for obsolete requests.

In search, update the typed text immediately and delay the network call. This preserves feedback without expensive work on every key.

Show feedback before secondary work

When an action triggers processing or network activity, acknowledge it quickly: change button state, show progress, update selection, preserve focus and accessible announcements, and defer analytics or secondary tasks.

Feedback cannot fix a blocked thread, but rendering the smallest useful state first can reduce presentation delay and perceived latency.

Review third parties commercially

Third-party scripts share the main thread. Build an inventory of owner, purpose, pages, bytes, CPU time and removal impact. Load tools only where needed, defer until consent or interaction, replace with server integrations where appropriate, remove duplicate tags and define CPU budgets.

Do not remove essential measurement without alignment across analytics, marketing and legal teams.

Use TBT as a clue, not a substitute

Lighthouse reports Total Blocking Time during its laboratory window. Reducing long tasks that worsen TBT may help INP, but the relationship is not guaranteed. The slow interaction may happen minutes later in a component Lighthouse never activates.

The correct workflow is: field confirms INP, profiling reproduces interactions, the fix reduces work, and field data verifies the trend.

Observation: applying a filter on mobile takes about 480 ms; 300 ms is spent recalculating and rendering every card. Action: filter normalized data, update only the list and defer analytics. Acceptance: selection receives immediate feedback, results remain correct and median interaction across five profiles stays below 200 ms on the test device.

After deployment, monitor errors, accessibility and conversion. A fast interface that removed necessary validation is not a success.

INP improves when teams treat CPU time and update scope as finite resources. The question is not only how much JavaScript exists, but when it runs, why it runs and whether it blocks the user's action.

Direct answers

Frequently asked questions

What is a good INP?

The current recommendation is INP of 200 milliseconds or less at the 75th percentile, separated between mobile and desktop.

Are TBT and INP the same metric?

No. Total Blocking Time is a laboratory metric related to long tasks during loading. It can indicate risk, but INP measures real interactions throughout a visit.

Does debounce always improve INP?

No. It can reduce repeated work but may also delay perceived response. Use it according to the event and provide immediate feedback when required.