Interaction to Next Paint: how to find and fix a slow INP

Craig AddymanUpdated 4 November 20266 min read

What INP measures

Interaction to Next Paint is the Core Web Vital for responsiveness. It times how long the page takes to show a visual response after an interaction. It looks at the whole visit, not just the first click.

• What counts: mouse clicks, taps and key presses.
• What doesn't: hovering, scrolling and zooming on their own.
• Which interaction sets the score: usually the slowest one. On pages with many interactions, one of the slowest is ignored for every 50.

Why tests can miss it

A page has no INP until someone interacts with it. A bot or crawler that doesn't click gets no value, and some lab tools don't report it. Total Blocking Time can be a rough stand-in, but it doesn't measure a real interaction.

The score Google uses comes from real Chrome visitors at the 75th percentile, split by mobile and desktop. See it in Search Console's Core Web Vitals report or PageSpeed Insights, where a page has enough visits. Then reproduce it yourself, ideally on a mid-range phone or with CPU throttling, as a fast laptop can hide the problem.

How to find the slow interaction

Copy// Logs each click, tap or key press event and where its time went
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.interactionId) continue;
    const inputDelay = Math.round(entry.processingStart - entry.startTime);
    const processing = Math.round(entry.processingEnd - entry.processingStart);
    const presentation = Math.max(0, Math.round(entry.startTime + entry.duration - entry.processingEnd));
    console.log(entry.name, entry.duration + ' ms', { inputDelay, processing, presentation }, entry.target);
  }
}).observe({ type: 'event', durationThreshold: 16, buffered: true });

Try interactions during load as well as after it. A click while scripts are still starting up is often the slowest one.

Where the time goes

How to fix it

• Input delay: break up long tasks during load, and find out whether a third-party script is the one holding the browser up.
• Processing: show the visual change first, then defer everything else, such as saving or analytics. Keep handlers small.
• Layout work: don't read layout values straight after changing styles in the same task, as that forces a layout.
• Presentation delay: reduce DOM size, add elements when they're needed, and consider content-visibility for off-screen sections. Be careful rendering large chunks of HTML from JavaScript.

Handing control back to the browser lets it paint before the heavy work starts:

Copybutton.addEventListener('click', async () => {
  showLoadingState();                                  // Visible change first
  await new Promise((resolve) => setTimeout(resolve)); // Hand back to the browser
  runSlowWork();                                       // Then the heavy work
});

A loading state isn't a fix for slow work, but it does mean the visitor sees a response straight away. For the other two Core Web Vitals, see Largest Contentful Paint and Cumulative Layout Shift.

How crawlers report this

Crawlers report likely causes, not which click was slow. These labels come from PageSpeed data, so they can change between versions.