INP debugging for product teams

What INP measures

On March 12, 2024, INP took over from First Input Delay as the Core Web Vital for responsiveness (source 1). It observes mouse clicks, taps and key presses, but not hovering, scrolling or zooming, and reports a value close to the slowest interaction in a visit, ignoring outliers on pages with many interactions. A value of 200 ms or less at the 75th percentile of page loads is good; above 500 ms is poor (source 2).

Each interaction has three parts: input delay before handlers start, processing time while they run, and presentation delay until the next frame is painted (source 2). Fixes differ for each part, which is why a single INP number is only a starting point.

Why INP is hard to debug alone

INP is a field metric. It depends on what real users click, on which devices, at which moment of the page's life. A developer testing on a fast laptop, clicking after the page has settled, often cannot reproduce it. Three gaps tend to block teams:

• No attribution. Aggregate field data, such as the Chrome UX Report, says INP is poor but not which element or handler causes it.
• Timing. Many slow interactions happen while start-up work or hydration is still running, so they only appear if you click early.
• Device spread. An interaction that takes 120 ms on a laptop can exceed 500 ms on a phone with a much slower CPU.

How we find the slow interactions

1. 01

   Read what field data exists

   Chrome UX Report data for your origin and pages, and any real-user monitoring you collect. If you collect nothing yet, we can add a small, privacy-conscious collector as part of the engagement (see real-user monitoring).

2. 02

   Collect attribution

   The attribution build of Google's web-vitals library reports the interaction target, its type, the three phases and the Long Animation Frames entries that overlap the interaction, including the scripts involved (source 3). A week or two of this data can narrow the search to a handful of elements.

3. 03

   Reproduce under realistic conditions

   We replay the worst interactions in DevTools with CPU throttling and at the moment of the page's life the data points to, such as during hydration.

4. 04

   Attribute and split

   For each interaction we record which phase dominates and which code fills it, using traces and Long Animation Frames script attribution (source 4).

5. 05

   Plan fixes per phase

   Input delay points to competing work on the main thread; processing means heavy handlers; presentation delay means large DOM updates or expensive style and layout.

Typical causes we look for

• Hydration or start-up scripts still running when users first tap.
• Handlers that synchronously filter, sort or render large lists.
• State updates that re-render far more of the component tree than changed.
• Analytics or tag code that runs inside the same task as the user's click.
• Expensive style recalculation caused by broad selectors or very large DOM trees.
• Layout reads immediately after DOM writes, forcing synchronous layout.

Interactions people forget to test

Lab testing tends to cover the obvious clicks: menus, buttons, links. Field attribution often points elsewhere. Typing in search boxes, where every key press is an interaction; opening select menus and date pickers; dismissing cookie banners and modals; and keyboard navigation through long lists all count towards INP. So do interactions that happen while a page is still loading. Our reproduction step works through the interactions the data names, not only the ones that seem important in a demo.

What you receive

A list of the interactions behind your INP, ranked by how much they contribute, each with its phase breakdown, the code responsible, and a fix proposal. You also get the trace files, any collector code we added, and a walkthrough call. After your team ships fixes, we can compare attribution data before and after.

How fixes map to phases

An interaction rarely has only one problem. Fixing the dominant phase first tends to reveal the next one, which is why we retest after each round of changes rather than planning everything at once.

Questions about INP work