Fixing Poor Interaction to Next Paint (INP)

What INP actually measures

Every time a visitor clicks, taps or presses a key, the browser has to run whatever JavaScript is listening for that input and then draw a new frame showing the result. INP is the time from the input to that next frame. Hovering and scrolling are not counted; only discrete interactions are.

The browser records every qualifying interaction during the whole visit, not just the first. When the visitor leaves, the page's INP is the slowest of those interactions. On pages where people interact a great deal, one outlier is ignored for every 50 interactions, so a single freak delay on a long session does not dominate. Google then takes the 75th percentile of those per-visit values across all real Chrome users over 28 days.

The three phases of one interaction

Each interaction breaks into three parts, and the fix depends entirely on which one is large:

1. Input delay. The wait before your event handler even starts, because the main thread was busy with something else: a script still loading, a timer firing, an analytics tag doing its work.
2. Processing duration. The time your own handlers for that input take to run, including every listener attached to the element and its ancestors.
3. Presentation delay. The time after the handlers finish until the frame is painted: style recalculation, layout, paint and compositing of whatever changed.

A menu that opens slowly because a chat widget was busy has an input-delay problem. A filter that re-sorts 2,000 products synchronously has a processing problem. A button that toggles a class on the <body> and forces the browser to restyle a DOM of 6,000 nodes has a presentation problem. Treating all three the same way wastes time.

The usual causes, by phase

Third-party scripts turn up in more than one row. They add long tasks that cause input delay, and some attach their own click listeners, which adds to processing time for every tap on the page.

How to find the interaction that fails

INP is a field metric. Lighthouse cannot measure it because nobody clicks anything during a lab run; it shows Total Blocking Time instead, which hints at input delay during load but says nothing about a slow handler on a filter button. You need data from real visitors first, then a lab session to reproduce what they did.

Start from the field

The Core Web Vitals checker shows the field INP for the URL and the origin from the Chrome UX Report, on mobile and desktop. The Search Console Core Web Vitals report groups URLs with the same problem, which usually points to one template. Neither tells you which button was slow, so the next step is to collect that yourself.

Collect attribution from your own visitors

Google's open-source web-vitals library has an attribution build that reports, for the interaction that set INP, the element that was interacted with, the type of input and the length of each phase. Send it to your analytics and you will see which elements fail most often.

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  const a = attribution;
  sendToAnalytics({
    metric: 'INP',
    value: Math.round(value),
    rating,                        // 'good' | 'needs-improvement' | 'poor'
    target: a.interactionTarget,   // a CSS selector for the element
    type: a.interactionType,       // 'pointer' or 'keyboard'
    inputDelay: Math.round(a.inputDelay),
    processing: Math.round(a.processingDuration),
    presentation: Math.round(a.presentationDelay),
    loadState: a.loadState         // was the page still loading?
  });
});

A few days of data is usually enough. Sort by target and look for the selectors that appear again and again with a poor rating. A loadState of loading or dom-interactive means people tapped before the page settled, which points at input delay from start-up scripts rather than at the handler.

Reproduce it in DevTools

Open Chrome DevTools, go to the Performance panel and set CPU throttling to a 4x or 6x slowdown so a desktop behaves more like a mid-range phone. Recent versions of Chrome show live interaction timings in this panel as you click, which is a quick way to spot the slow control. For detail, start a recording, perform the interaction, stop the recording and find the interaction in the Interactions track. Hovering over it shows the input delay, processing duration and presentation delay. Tasks with a red corner in the Main track are long tasks over 50 milliseconds; expand them to see which script and which function ran.

Code patterns that fix each phase

Yield to the main thread inside long work

The single most useful technique is to split one long task into several short ones so the browser can paint and handle other input in between. scheduler.yield() does this in Chromium-based browsers; older browsers can fall back to a zero-length timeout.

function yieldToMain() {
  if (globalThis.scheduler && typeof scheduler.yield === 'function') {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function applyFilters(products, filters) {
  const results = [];
  for (let i = 0; i < products.length; i++) {
    if (matches(products[i], filters)) results.push(products[i]);
    if (i % 200 === 0) await yieldToMain();   // let the browser breathe
  }
  return results;
}

Show feedback first, do the rest after the paint

The visitor needs to see that their tap worked. Update the button, spinner or counter straight away, then push anything that is not needed for that frame, such as analytics calls, saving to storage or recalculating recommendations, until after the browser has painted.

button.addEventListener('click', () => {
  button.classList.add('is-loading');   // visible change, cheap
  requestAnimationFrame(() => {
    setTimeout(() => {                 // runs after the next paint
      updateBasket();
      trackAddToBasket();
    }, 0);
  });
});

Avoid forced layout in loops

Reading a layout property after writing a style forces the browser to calculate layout immediately. Inside a loop that becomes dozens of layouts in one handler. Read everything first, then write everything.

// Slow: read, write, read, write ...
cards.forEach(c => { c.style.height = c.offsetWidth * 0.75 + 'px'; });

// Faster: all reads, then all writes
const widths = cards.map(c => c.offsetWidth);
cards.forEach((c, i) => { c.style.height = widths[i] * 0.75 + 'px'; });

Keep off-screen rendering cheap

For long pages with many sections, content-visibility: auto lets the browser skip rendering work for sections far outside the viewport. Pair it with contain-intrinsic-size so the scrollbar does not jump. For lists of hundreds or thousands of rows, render only the visible rows (virtualisation) instead of all of them.

.product-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

The fix, step by step

Platform notes

WordPress

Poor INP on WordPress sites nearly always comes from plugins that add JavaScript to every page: sliders, pop-up builders, chat, social feeds and several analytics tools at once. Page builders also produce very deep DOMs, which feeds presentation delay. Check which scripts own the long tasks, dequeue plugin scripts on pages that do not use them, and prefer the "delay JavaScript until interaction" setting in a performance plugin only for tags that genuinely are not needed, since delayed scripts all run at once on the first tap and can make that first interaction worse. The WordPress Core Web Vitals guide covers this in more depth.

Shopify

Installed apps inject scripts into the storefront, and each can listen for clicks on product forms and cart buttons. Variant pickers and cart drawers that re-render a large part of the page on every change are common processing-time problems. Remove apps you no longer use, since some leave code behind in the theme, and test the add-to-basket and variant selection interactions specifically.

React, Next.js and other frameworks

Hydration makes the page unresponsive until the framework has attached its handlers, which shows up as input delay for early taps. Keeping more components on the server, splitting client bundles and lazy-loading interactive widgets that sit below the fold all help. Inside components, use startTransition or useDeferredValue for expensive updates such as filtering, and memoise large lists so a small state change does not re-render them. The Next.js and Nuxt guide goes further into server and client components.

Hand-written and static sites

Here the usual culprits are third-party tags and older libraries such as jQuery plugins that bind many handlers and do heavy DOM work on every event. Event delegation, a single listener on a parent rather than one per item, reduces set-up work and memory, though it does not make an individual handler faster on its own.

Edge cases and misleading readings

• Good lab score, poor field INP. This is normal. Lighthouse does not interact with the page. Use Total Blocking Time as a rough warning sign only, and trust field attribution for the real answer.
• INP only poor on mobile. Phones have slower processors, so the same JavaScript takes several times longer. Throttle the CPU when testing, and see the mobile-only failures guide.
• Poor INP from interactions during load. If attribution shows a loadState before complete, visitors are tapping while start-up scripts run. Reducing and deferring those scripts matters more than optimising the handler.
• Slow keyboard interactions in search boxes. A handler that filters or fetches on every key press can fail INP even if each call is modest. Update the input immediately and debounce the expensive part.
• Interactions inside iframes. Embedded content such as a third-party booking widget is measured separately in its own frame, and you cannot fix its code. You can load it only when needed, or replace it with a link to the provider's own page.
• Pages with no field data. Low-traffic pages have no CrUX figures of their own. Your own attribution data is then the only reliable measure.

Keeping INP good

• Keep the attribution reporting running. Leave the web-vitals reporting live so a new tag or feature that adds long tasks shows up in days rather than a month later.
• Review every new third-party tag. Before adding a script through a tag manager, record a throttled interaction with and without it.
• Set a budget for JavaScript. Agree a maximum size for the scripts each template loads and fail the build or flag the pull request when it grows beyond that.
• Test interactions, not just loads. Add the key interactions, such as opening the menu, applying a filter and adding to basket, to your release checks with a throttled CPU.
• Watch long tasks. The Long Animation Frames API, available in Chrome, reports frames that took too long and which scripts contributed. Logging it alongside INP makes regressions easy to trace. See also fixing long tasks.