Tags: web-dev concept

Interaction to Next Paint

Date: 2026-08-16

---

How long from a tap to seeing something happen — across the whole visit, not just the first interaction. It exposed a problem its predecessor hid: pages that respond instantly on load and become unusable once every third-party script has arrived.

---

What it is

Interaction to Next Paint (INP) measures the latency of interactions throughout a page’s life, reporting roughly the worst one. It covers clicks, taps and key presses — not scrolling or hovering.

Good is ≤ 200ms at the 75th percentile. See Core Web Vitals.

It replaced First Input Delay (FID) in March 2024. FID measured only the delay before the first interaction’s handler started, which meant a page could score perfectly while every subsequent interaction was slow and while the handler itself took a second to do anything.

The three phases

  user taps
      │
      ├── INPUT DELAY ──────┤   waiting for the main thread to be free
      │                     │
      ├── PROCESSING TIME ──┤   your event handlers running
      │                     │
      ├── PRESENTATION ─────┤   style, layout, paint, composite
      │                     │
                        user sees the result

Phase	Long means	Fix
Input delay	The thread was already busy	Long Tasks and Blocking, Third-Party Scripts
Processing	Your handler does too much	Yield, defer, do less
Presentation	Heavy layout or paint after the change	Reflow and Repaint, simplify the DOM

Input delay usually dominates, which is the counterintuitive part: the interaction was slow because of something entirely unrelated that happened to be running. Optimising the handler wouldn’t have helped.

Worked, from Long Tasks and Blocking:

tap arrives while a 200ms third-party task is running, 180ms remaining

  180ms   input delay      ← nothing to do with your handler
   30ms   processing
   16ms   presentation
  ─────
  226ms   INP for this interaction

Why it’s the hard one

LCP and CLS are load-time problems you can fix once. INP is a whole-session problem, and it gets worse the longer someone stays — more scripts have loaded, more listeners are attached, the DOM is larger, memory is fuller.

It’s also the metric most sensitive to device. A mid-range Android phone is several times slower than a development machine, so a handler that feels instant to you is measurably slow to a real customer. If you only test on your own laptop, INP is invisible.

Fixing it

Reduce input delay — the biggest lever:

• Audit Third-Party Scripts. Tag managers, chat widgets, review platforms and personalisation tools are the usual occupants of the main thread — Tag Manager Performance
• Break up long tasks with genuine yields. await Promise.resolve() does not yield — see Tasks and Microtasks
• Defer non-essential work until after first interaction, or to requestIdleCallback
• Move pure computation to a worker

Reduce processing time:

• Do the visible thing first, the rest after. Update the UI, then fire the analytics and the recommendation call
• Debounce handlers on high-frequency events — Event Handling
• Delegate rather than attaching thousands of listeners

Reduce presentation delay:

• Avoid triggering layout on interaction where a composite-only change would do — The Rendering Pipeline
• Keep the DOM small; virtualise long lists
• content-visibility: auto on off-screen sections

The pattern that catches everyone

button.addEventListener('click', async () => {
  await trackEvent('add_to_basket');   // network round trip
  showBasketDrawer();                  // the user has been waiting
});

The user waits for an analytics call before seeing the drawer. Reverse it — show the UI immediately, fire tracking afterwards. Measurement should never be on the interaction’s critical path, and this is one of the most common real causes of poor INP on retail sites.

Measuring it

• Field only, realistically. Lab tools can simulate interactions but not the mix of real ones
• The web-vitals library reports INP with attribution — which element, which phase, which script. That attribution is what makes it actionable rather than just a number
• Total Blocking Time in Lighthouse is a reasonable lab proxy, since it measures the same main-thread congestion
• Segment by device and template. INP is dominated by the slowest devices, and site-wide figures hide which page is responsible