Optimizing INP: The Core Web Vital That Replaced FID

First Input Delay only ever measured one thing: how long the browser waited before it could start handling the very first click, tap, or key press on a page. It quietly retired in March 2024, replaced by Interaction to Next Paint, a Core Web Vital that watches every interaction across the entire visit and reports the slowest one that still counts after outliers are trimmed. If your team spent years chasing a good FID score only to watch INP turn red in Search Console, this is why: FID never cared what happened after the first tap, and most real slowness happens later, deep into a session, once state, listeners, and DOM nodes have piled up.

This post walks through what INP actually measures, why long JavaScript tasks are almost always the root cause of a poor score, and the concrete techniques that bring INP back under the two hundred millisecond good threshold: breaking up long tasks, yielding to the main thread with modern scheduling APIs, trimming unnecessary work inside event handlers, and instrumenting real users with the web-vitals library so you are optimizing against actual field data instead of a single lab trace.

What INP Actually Measures

INP looks at every click, tap, and keyboard interaction that occurs during a page visit and calculates a latency value for each one, made up of three phases: input delay before the event handler starts running, processing time while the handler executes, and presentation delay until the browser paints the next frame. INP then reports whichever interaction was slowest after a small number of statistical outliers are discarded on interaction-heavy pages, evaluated at the seventy fifth percentile across real visits, split by mobile and desktop. A page with one sluggish dropdown buried on scroll can still fail INP even if every other click feels instant, because the metric is designed to catch the worst experience a typical visitor encounters, not the average one.

Why Long Tasks Wreck Responsiveness

The browser's main thread can only do one thing at a time. Layout, style recalculation, JavaScript execution, and painting all compete for the same thread, so any script that runs uninterrupted for more than fifty milliseconds is classified as a long task and blocks everything else, including the click handler a user is waiting on. Long tasks creep in through a handful of common culprits on typical Next.js and React applications.

• Large synchronous state updates that re-render an oversized component tree in one pass, especially tables, dashboards, or lists rendering hundreds of rows without virtualization
• Third-party scripts such as chat widgets, analytics tags, or ad libraries that hijack the main thread during hydration or on click, often outside the application's own control
• Client-side data transformation, sorting, filtering, or JSON parsing of large payloads performed synchronously inside an event handler instead of being chunked or moved off the main thread

Breaking Up Long Tasks and Yielding to the Main Thread

The fix for a long task is rarely to make the work itself faster; it is to chop the work into smaller pieces and hand control back to the browser between pieces so it can paint, run input handlers, and stay responsive. This pattern is called yielding. Historically developers faked it with setTimeout, which defers a callback to the end of the task queue, but that approach lets lower priority work jump ahead of what the user is waiting on. The scheduler.yield method, which shipped stable in Chrome 129 in September 2024 and is now supported in Chromium-based and Firefox browsers, solves that by pausing execution and placing the continuation at the front of the queue, so your code resumes as soon as any higher priority input handling finishes, rather than waiting behind every other queued timer.

// Feature-detect scheduler.yield(), fall back to a microtask-friendly helper
function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return window.scheduler.yield()
  }
  // Fallback: postMessage-based macrotask yield (setTimeout(0) is throttled)
  return new Promise((resolve) => setTimeout(resolve, 0))
}

async function processLargeList(items, renderRow) {
  for (let i = 0; i < items.length; i++) {
    renderRow(items[i])

    // Yield every N items instead of every item, or every frame budget (~5ms)
    if (i % 20 === 0) {
      await yieldToMain()
    }
  }
}

// In an interaction handler: paint feedback first, then do heavy work
button.addEventListener('click', async () => {
  showSpinner()          // cheap, paints immediately
  await yieldToMain()     // let the browser paint the spinner
  await processLargeList(rows, renderRow)
  hideSpinner()
})

A Practical Yielding Checklist

When you are refactoring an interaction that trips a long task, work through these steps in order rather than reaching for scheduler.yield everywhere by default, since yielding too often adds its own overhead.

1. Give immediate visual feedback first, such as a pressed state or a spinner, before doing any expensive work, so the paint the user is waiting for happens within a few milliseconds regardless of how long the rest of the interaction takes
2. Chunk loops over large arrays so each chunk fits comfortably inside a five millisecond budget, yielding between chunks with scheduler.yield where supported and falling back to a macrotask-based yield for browsers that lack it
3. Move genuinely heavy computation, such as parsing large JSON payloads or complex sorting, into a Web Worker so the main thread is never blocked by it in the first place, reserving yielding for work that must stay on the main thread because it touches the DOM

Measuring Real User INP with web-vitals

Lab tools like Lighthouse simulate a handful of scripted interactions on a single machine, which is useful for catching regressions in CI but tells you nothing about how your actual visitors, on their actual devices and networks, experience responsiveness. Google's open source web-vitals library listens to the same Event Timing API that Chrome uses internally and reports INP directly from real sessions, including attribution data that names the DOM target and event type responsible for the slowest interaction, letting you go straight from a dashboard alert to the exact component causing it.

import { onINP } from 'web-vitals'

onINP((metric) => {
  // metric.value is in milliseconds, metric.rating is
  // 'good' | 'needs-improvement' | 'poor'
  const target = metric.attribution?.interactionTarget
  const eventType = metric.attribution?.interactionType

  navigator.sendBeacon('/analytics/web-vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    target,
    eventType,
    id: metric.id,
  }))
}, { reportAllChanges: false })

Rolling Out INP Monitoring Without Overengineering It

You do not need a custom analytics pipeline to start tracking INP in production. A small integration layered onto whatever you already use for page views is enough to start finding real regressions within days.

• Call the onINP function once on every page and forward the metric name, value, rating, and attribution target to your existing analytics endpoint using sendBeacon so the report survives page unload
• Segment the dashboard by device type and connection speed before drawing conclusions, since a mid-range Android phone on a throttled connection will report a very different INP distribution than the desktop Chrome browser most engineers test on
• Set an alert threshold at the two hundred millisecond good boundary at the seventy fifth percentile rather than watching the average, because INP is explicitly designed to surface the worst common experience, not a mean that hides it