INP in practice: finding and fixing slow interactions

Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024, and a site that passed FID comfortably can still fail INP. FID only timed the wait before a page began handling the first interaction; INP times the whole response to clicks, taps and key presses throughout the visit. Slow interactions leave evidence, though. This is how we find them in field data and fix them.

What INP measures

INP observes every click, tap and key press during a visit (scrolling and hovering don’t count) and reports one of the slowest. Each interaction has three phases:

• Input delay: the wait before your event handlers can start, usually because the main thread is busy with other work.
• Processing duration: the time your event handlers take to run.
• Presentation delay: the time from the end of the handlers to the next frame on screen, which covers style recalculation, layout and paint.

The life of an interaction

1. InputA click, tap or key press
2. Input delayThe main thread finishes other work first
3. ProcessingEvent handlers run
4. PresentationStyle, layout and paint
5. Next paintThe visitor sees a response

This is why passing FID proved so little. A page could start handling the first click quickly and still take half a second to show anything, because the handler did too much or the browser had a huge page to re-render. FID never saw that. INP does, and it watches every interaction, not only the first.

Google assesses INP at the 75th percentile of real visits: 200 ms or less is good, and over 500 ms is poor.

Core Web Vitals thresholds

LCP Largest Contentful Paint · loading

Good≤ 2.5 sNeeds improvement2.5–4 sPoor> 4 s

INP Interaction to Next Paint · responsiveness

Good≤ 200 msNeeds improvement200–500 msPoor> 500 ms

CLS Cumulative Layout Shift · visual stability

Good≤ 0.1Needs improvement0.1–0.25Poor> 0.25

Finding slow interactions

Start with field data, which tells you whether real visitors have a problem, then narrow it down to the interaction and the phase.

Search Console’s Core Web Vitals report. It groups similar URLs, so you can see which templates fail INP on mobile and on desktop. In our audits, listing pages with filters and pages carrying heavy tag stacks are frequent offenders.

CrUX data in PageSpeed Insights. Field INP for a URL or the whole origin over the previous 28 days. It confirms the problem but can’t tell you which interaction caused it.

The web-vitals library’s attribution build. Add it to your pages and send the results to your analytics, and you’ll know which element was involved and how long each phase took:

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

onINP(({ value, attribution }) => {
  sendToAnalytics({
    inp: value,
    element: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processing: attribution.processingDuration,
    presentation: attribution.presentationDelay,
  });
});

Group the results by template and element, and a pattern usually emerges quickly.

The DevTools Performance panel. Reproduce the interaction with CPU throttling switched on: a 4x or 6x slowdown is closer to a mid-range phone than to your laptop. The live metrics view updates INP as you interact, and a recorded trace shows the long tasks behind a slow interaction.

The Long Animation Frames API. Available in Chromium-based browsers, it reports frames that took longer than 50 ms and attributes the time to specific scripts and functions. The attribution build includes these entries, which is often the quickest way to prove that a third-party tag is to blame.

Common causes

Most slow interactions come down to a main thread that is busy when the visitor acts, or one that is given too much to do in response.

• Long tasks. Any task over 50 ms blocks the main thread. If one is running when the visitor clicks, the click waits, and that wait is input delay.
• Heavy event handlers. A click that filters a long list, recalculates a basket or validates a whole form in one go.
• Third-party scripts and tag managers. Analytics, chat, testing and consent tools often attach their own listeners to the same clicks, and their work counts against your interaction.
• Large re-renders and hydration. Frameworks that re-render a big component tree for a small change, or hydrate the whole page while the visitor is already trying to use it.
• Layout thrashing. Code that changes styles and then reads layout values such as offsetHeight in a loop, forcing the browser to recalculate layout again and again.

Where one slow click spends its time

Input delay80 ms

Processing duration300 ms

Presentation delay140 ms

Whole interaction520 ms

Fixes that work

Break up long tasks and yield to the main thread. Split work into smaller chunks and let the browser respond to input between them. scheduler.yield() does this in browsers that support it (currently Chromium-based ones), and a setTimeout fallback covers the rest:

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

async function onFilterClick(button) {
  button.classList.add('is-loading'); // feedback first
  await yieldToMain(); // let the browser paint
  applyFilters(); // then the heavy work
}

Show visual feedback first and do the work after. The visitor needs to see that something happened: a pressed state, a spinner, a menu opening. Saving, analytics calls and recalculation can follow once that frame has been painted.

Debounce input handlers. Search-as-you-type boxes and live filters shouldn’t rerun on every keystroke. Wait until the visitor pauses.

Reduce DOM size. Fewer elements mean less style and layout work on every update, which shortens presentation delay. Paginate or virtualise long lists, and remove hidden markup you don’t need.

Defer non-critical third parties. Load chat widgets when someone asks for them, review your tag manager regularly and remove the tags nobody uses.

Move heavy work to web workers. Parsing, sorting and filtering large datasets can run off the main thread entirely, which leaves it free to respond.

Proving the fix

Field data covers a rolling 28-day window, so give a fix about four weeks before you judge it in CrUX or Search Console. Your own web-vitals data will show the change sooner, and it tells you whether the element you fixed has dropped out of the worst offenders.

We check INP as part of our technical SEO work, and when the cause is the front end itself, our web design and development team can rebuild the slow components. For how responsiveness fits alongside the rest of this year’s work, see where we’re focusing in 2025.

---

Not sure which interactions are slowing your pages down? Request a free SEO audit and we’ll include your real-user INP, LCP and CLS, with the likely causes of any failures.