How to Fix INP: Trace the Slow Interaction Before Changing Code

A slow interaction is a better starting point than a bundle-size target. Interaction to Next Paint (INP) measures responsiveness in Core Web Vitals: click, tap and keyboard input to the next paint. Field assessment uses the 75th percentile, separately for mobile and desktop: good at 200 ms or less, needs improvement above 200 through 500 ms, poor above 500 ms. These boundaries classify the outcome; they do not identify the responsible function.

Sources:[2] web.dev

Choose a journey with a concrete failure: opening navigation while the page initializes, changing a catalog filter after scrolling, or submitting a form with validation errors. Write down the route, initial state, input, expected visible response and whether the problem happens during loading or later. A trace of an idle page cannot test a complaint about a filter used several minutes into a visit.

Where real-user attribution is available, use it to choose the journey. The attribution build of web-vitals exposes an interaction target and the input, processing and presentation parts of the reported interaction. Inspect the library version and collection policy before adding instrumentation. Prefer an allowlisted component name to raw text or a selector containing user data; never attach form values to performance telemetry.

Sources:[5] web.dev

Sources:[4] Chrome for Developers

Sources:[10] Chrome for Developers

For the distinction between URL-level field data, origin data and synthetic testing, use the Core Web Vitals testing guide. Here the task is narrower: identify the slow interaction, change one cause, and verify that the action still completes correctly.

Read the interaction from left to right. Input delay is the wait before event callbacks start. Processing duration covers the callbacks. Presentation delay is the interval after processing until the next frame is presented. A fix aimed at the wrong interval can remove code without changing the delay that the user experiences.

Sources:[3] web.dev

Sources:[3] web.dev

Sources:[3] web.dev[4] Chrome for Developers

Do not classify work by its name alone. A geometry read after style invalidation can force layout inside a JavaScript callback, so rendering-related cost can appear during processing. Inspect the call stack and the forced-reflow evidence before assigning every layout problem to presentation delay.

Sources:[3] web.dev[9] Chrome for Developers

Keep the hypothesis small enough to reject. “The application has too much JavaScript” is not a test. “This filter sorts the full dataset synchronously before acknowledging the selection” is: hold the dataset and selection constant, change the sort scheduling, and inspect both the recorded delay and the final order. A shorter interaction with incorrect results is a failed change.

When a callback owns a large piece of synchronous work, splitting it into smaller functions does not create a scheduling opportunity. The browser still executes them in the same task. An already-resolved promise is not a substitute: its continuation is a microtask, and microtasks are drained before the browser may update rendering.

Sources:[1] MDN Web Docs[7] web.dev

The laboratory kit uses scheduler.yield() when available and a timer when it is not. Feature detection is part of the implementation, not an optional compatibility note: MDN still marks this API as having limited availability. Both paths resume in a later task, but their scheduling priorities are not identical.

Sources:[6] MDN Web Docs[11] Chrome for Developers

function yieldToBrowser(forceTimer = false) {
  if (!forceTimer && typeof globalThis.scheduler?.yield === 'function') {
    return globalThis.scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

Sources:[6] MDN Web Docs[11] Chrome for Developers

In the complete example, a run validates the workload, marks the operation busy, and prevents a second run from overwriting its state. The yielding mode reports progress between chunks. A cooperative cancellation token discards a partial result; the final checksum is published only when all work has completed. Cleanup restores the controls even when the operation fails. These constraints matter more than making the helper one line shorter.

A yield also does not promise that every pending timer will run before the continuation. The native API prioritizes continuations differently from ordinary timer tasks. Test the interaction that must remain responsive—such as Cancel or a subsequent filter change—instead of treating the number of yield calls as a performance result.

Sources:[11] Chrome for Developers

For a real component, define who owns cancellation when the route changes, which state can be read between chunks, and how a newer request supersedes an older one. Yielding introduces points where other work can intervene. Do not ship a scheduling change until those intermediate states are intentional and stale results cannot replace the current view.

Download the interaction laboratory. It contains plain HTML, CSS and JavaScript, a measurement worksheet, and operating instructions. There are no external scripts or telemetry. Open index.html in a browser from the extracted folder; where local-file policies prevent this, serve that folder with your existing local development server. The bundled code was executed in a DOM harness, not through a production HTTP route.

Sources:[2] web.dev

In the supplied functional check, all three modes completed 10,000 items with checksum 2364371375. The native yielding path and forced timer fallback both ran in Chromium 144.0.7559.96. A scheduled high-priority test action exercised Ping and cancellation, and an invalid workload was rejected. This is a synthetic correctness check, not a field sample, an Event Timing measurement or evidence that one mode is faster on your application.

Yielding is not a reason to keep unnecessary work. If the trace shows repeated full-data processing for each input, first decide whether the same result can be obtained with less computation. If one indivisible calculation dominates, a worker may be more appropriate than increasingly small chunks around it. Workers cannot directly manipulate the DOM; message transfer and the eventual main-thread update remain part of the design.

Sources:[8] MDN Web Docs

Sources:[3] web.dev[8] MDN Web Docs[9] Chrome for Developers

Treat these as candidate changes, not a checklist to apply all at once. A worker is a poor answer to a problem dominated by rendering. A spinner does not repair a lost form submission. Removing content to obtain a shorter trace changes the user task. Keep the expected result fixed while changing the mechanism that produces it.

Performance changes can also move instability elsewhere. When a deferred result expands a panel, verify its reserved space and the final focus position. Use the CLS debugging guide for unexpected movement, and the LCP guide when the first useful content is late. Those are separate investigations; a lower INP does not certify them.

I would not accept a screenshot of a lower number as the release criterion. Keep the baseline trace, the changed build, the exact journey and the expected output together. Start with paired repetitions under fixed conditions—for example, five baseline and five changed runs as a practical investigation batch, not a claim of statistical certainty. Record the spread as well as the typical result and investigate inconsistent runs rather than deleting them.

Do not average route percentiles to manufacture a site-wide percentile, and do not call the longest of a few manual clicks the production INP distribution. Retain the measurement scope in the ticket: one reproduced interaction, a real-user page cohort, or an origin-level report. The comparison is only as useful as the consistency of that scope.

Start the next investigation by saving one trace of the action that fails, then name the interval you can change. Reduce or reschedule only the work supported by that evidence. The fix is complete when the response is usable, the operation remains correct, and the relevant post-release measurements confirm the change—not when a spinner appears sooner.