INP Debugger

About the INP Debugger

The INP Debugger measures how quickly a page responds when someone interacts with it. Interaction to Next Paint is one of Google's Core Web Vitals. It records the delay between a tap, click, or key press and the next frame the browser paints, so a high INP means the page feels slow and unresponsive.

INP is normally a field metric, because it depends on real people interacting with the page. A lab tool has no real users, so this tool does the next best thing. It loads your page in a real Chromium browser on a throttled mobile and desktop connection, runs a set of common interactions such as clicking buttons, opening menus, and typing in inputs, and measures the slowest one. It also reports Total Blocking Time, which is the lab proxy Lighthouse uses for INP, and pulls real user INP from the Chrome User Experience Report so you can compare the lab result with the field.

A good INP is 200 milliseconds or less. Between 200 and 500 milliseconds needs improvement. Above 500 milliseconds is poor. Reports are shareable and stay available for 14 days.

How to fix the Interaction to Next Paint

Every interaction has three phases that add up to the total: input delay, processing, and presentation. The fastest way to improve INP is to find the biggest phase and work on that first. This report highlights it for you.

Input delay (the main thread was busy). The browser could not start your event handler because it was busy with other work. Break up long tasks so the browser can respond between them, defer or lazy-load third-party scripts such as tags, chat widgets, and analytics, and reduce the cost of hydration on framework apps.

Processing (the handlers took too long). Your event handlers did too much work before the browser could paint. Yield to the main thread inside long handlers with scheduler.yield or an awaited timeout, debounce expensive work, and cut unnecessary framework re-renders and large state updates.

Presentation (the next frame was slow to paint). The handlers finished but the browser took too long to draw the result. Shrink the DOM, use content-visibility for off-screen sections, and avoid layout thrash by batching DOM reads and writes.

Known Issues

INP is a field metric, so a lab estimate has real limits.

• The tool tests a fixed set of common interactions. It cannot know every journey on your site, so a slow interaction that we do not trigger will not appear. Use the field data to see the full picture.
• A synthetic click is not identical to a human one, so lab numbers are a guide, not an exact match for what your visitors feel.
• Throttling matters. On a fast machine most interactions look quick, so we throttle the CPU to mirror a mid-range phone.
• Sites that block data-center traffic, are very slow, or need a cookie click may fail to load. Try again, or test a URL that does not require interaction.

Frequently Asked Questions

What is a good INP score?

Google considers an INP of 200 milliseconds or less to be good. Between 200 and 500 milliseconds needs improvement. Above 500 milliseconds is poor. The score is measured at the 75th percentile of real visits.

Can INP be measured in a lab?

Not directly. INP needs real people interacting with the page, so lab tools have nothing to measure on their own. This tool scripts a set of common interactions, runs them under throttling, and reports the slowest one. It also shows Total Blocking Time, which is the lab proxy Lighthouse uses, and the real INP from the Chrome UX Report. Treat the lab number as a guide and confirm it in the field.

What are the three phases of an interaction?

Input delay is the time before your event handler starts, usually because the main thread was busy. Processing is how long your handlers run. Presentation is the time for the browser to paint the next frame. Together they add up to the interaction latency, and the largest phase points to the fix.

What is Total Blocking Time?

Total Blocking Time adds up the main-thread time that blocked input after the page first painted. Lighthouse and PageSpeed Insights use it as the lab stand-in for INP because it correlates with slow interactions. We report it on every page, even ones with no interactions to test.

Which interactions does the tool test?

It clicks common controls such as buttons, navigation toggles, tabs, and menus, and types into the first input it finds. It cannot know every journey on your site, so a slow interaction it does not trigger will not appear here.

How do I fix a high INP?

Find the largest phase in the breakdown. A large input delay means the main thread is busy, so break up long tasks and defer third-party scripts. A large processing time means the handlers do too much, so yield to the main thread and cut expensive work. A large presentation time means the paint is slow, so reduce the DOM size and avoid layout thrash.

Disclaimer

This is a lab tool. INP is a field metric, so the value here is an estimate from a fixed set of scripted interactions run once per device under throttled conditions. It is a controlled measurement, not a guarantee of what every visitor experiences, and it cannot cover every interaction on your site. Total Blocking Time is shown as an always-on companion, and the Chrome UX Report field data is shown alongside so you can compare the lab with the real world. Use this tool to find and fix slow interactions, then confirm the improvement in the field data over time.