Optimizing Long Tasks and INP: Measurably Improving Responsiveness

1. Why INP is the decisive interaction metric

Interaction to Next Paint, or INP, measures the time from a user interaction, such as a click or key press, to the browser presenting the next visible visual update. Unlike its predecessor First Input Delay, INP does not just look at the very first interaction on a page, it looks at all interactions during the entire page visit, and reports the worst representative value. That makes INP a considerably stricter and more honest metric for the actual responsiveness of an application.

Since INP replaced First Input Delay as a Core Web Vital, it is no longer enough to optimize only the first interaction of a session. A single page application that reacts quickly on the first click, but becomes sluggish after several minutes of use due to accumulated state and memory consumption, still gets a poor INP score. This shift forces teams to treat responsiveness as a continuous property of the entire session, not a one time loading moment.

According to Google's guidance, a good INP value is below two hundred milliseconds, while anything above five hundred milliseconds counts as poor. These thresholds are deliberately chosen to match human perception of immediate reaction. Anyone who wants to improve INP needs to understand exactly where in that time span the delay originates, because INP is made up of several sub phases, each with its own causes and its own solutions.

2. The three phases of an interaction and where INP originates

Every interaction relevant to INP goes through three phases: input delay, processing time and presentation delay. Input delay begins with the physical click or key press and ends once the event handler actually starts running. This phase becomes long when the main thread is already busy with another task at the moment of interaction, for example a running Long Task that forces the interaction into a queue.

Processing time covers the actual execution of all event handlers reacting to the interaction, including synchronous state changes and re-renders triggered in frameworks. This phase is the most directly influenceable by code, since it consists entirely of JavaScript the developer controls. Presentation delay, finally, describes the time from the end of the event handlers to the next painted frame, including style recalculation, layout and paint, and is often underestimated because it is not directly visible in one's own code.

For INP, the sum of all three phases counts, not just one alone. A team that only optimizes processing time but ignores that the main thread is blocked by an unrelated Long Task will still measure a poor INP value. That is why the first step of any INP optimization is always an analysis of which of the three phases accounts for the largest share of the total time in the concrete case.

// Measuring the three INP phases with the Event Timing API
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const inputDelay = entry.processingStart - entry.startTime;
    const processingTime = entry.processingEnd - entry.processingStart;
    const presentationDelay = entry.startTime + entry.duration - entry.processingEnd;

    console.log({
      interaction: entry.name,
      inputDelay: inputDelay.toFixed(1),
      processingTime: processingTime.toFixed(1),
      presentationDelay: presentationDelay.toFixed(1),
      total: entry.duration.toFixed(1),
    });
  }
}).observe({ type: "event", buffered: true, durationThreshold: 40 });

3. Long Tasks as the main cause of poor INP values

A Long Task, any main thread task lasting over fifty milliseconds, is the most common cause of a high input delay within INP. When an interaction arrives in the middle of a running Long Task, it has to wait until that Long Task is fully finished before the browser even begins executing the associated event handler. A single three hundred millisecond Long Task can dominate the entire INP measurement purely through bad timing.

Typical sources of Long Tasks that worsen INP are large initialization routines after load, extensive data processing in response to a previous interaction, and third party scripts like analytics or ad tags that work synchronously without regard for the main thread. Especially tricky are Long Tasks caused by internal framework reconciliation, when a state change re-renders a large number of components at once without the developer intending it that way.

The strategy against Long Tasks in the context of INP is not to avoid them entirely, which is often unrealistic with complex application logic, but to split them so that enough room remains between the parts for the browser to react to waiting interactions. This principle is called yielding and is the central lever for making Long Tasks INP friendly without reducing the total amount of work.

4. Yielding: giving the main thread deliberate pauses

Yielding means deliberately interrupting a long synchronous operation at predetermined points and briefly handing control back to the browser, so it can process waiting interactions, layout updates or other higher priority tasks. The simplest, though technically inelegant, method is setTimeout with zero milliseconds, which queues a task in the macrotask queue and thereby gives the browser a chance to render in between.

More effective for INP optimization is splitting a large loop into fixed size chunks, with a yield point between each chunk. What matters is how often and how granularly you yield: too rarely, and Long Tasks stay long enough to worsen INP, too often, and the overhead of constantly returning to the event loop noticeably slows down overall processing. The right balance is usually chunks that themselves stay well under the fifty millisecond Long Task threshold, roughly ten to twenty milliseconds per chunk.

An often overlooked aspect: yielding only actually helps the INP measurement if the yield point is chosen so the browser genuinely gets an opportunity to process a waiting interaction before the next chunk starts. A yield in the middle of a computation that immediately continues with even more synchronous work, without giving the event loop real priority, brings hardly any improvement for INP.

// Yielding a long operation into chunks the main thread can interrupt
async function renderLargeTable(rows) {
  const CHUNK_SIZE = 50;

  for (let i = 0; i < rows.length; i += CHUNK_SIZE) {
    const chunk = rows.slice(i, i + CHUNK_SIZE);
    appendRowsToDOM(chunk);

    // Yield after each chunk so pending interactions get a chance to run
    await yieldToMain();
  }
}

function yieldToMain() {
  if ("scheduler" in window && "yield" in window.scheduler) {
    return window.scheduler.yield();
  }
  // Fallback: MessageChannel yields faster than setTimeout(0)
  return new Promise((resolve) => {
    const channel = new MessageChannel();
    channel.port1.onmessage = () => resolve();
    channel.port2.postMessage(null);
  });
}

5. The Scheduler API and task prioritization

The native Scheduler API with scheduler.postTask and scheduler.yield was designed specifically to enable yielding and prioritization without the detours of setTimeout or MessageChannel. With scheduler.postTask a task can be queued with one of three priority levels: user-blocking for tasks completing a direct user interaction, user-visible as the default for visible but non critical work, and background for tasks that can wait until the main thread is free.

This prioritization is especially valuable for INP because the browser can internally decide to interrupt a background priority task as soon as a user-blocking task arrives through an interaction. Without the Scheduler API, a developer has to manually rebuild this behavior with timers and state variables, with the Scheduler API the browser takes over the decision based on actual system load and waiting interactions.

The fallback for browsers without Scheduler API support remains important, since the API is not yet available everywhere. A robust pattern checks availability at runtime and falls back to MessageChannel when unsupported, which offers noticeably lower delay returning to the event loop compared to setTimeout with zero milliseconds, and thereby represents a solid basis for INP optimization even as a fallback.

// Using scheduler.postTask to prioritize interaction-critical work
async function handleSearchInput(query) {
  // User-blocking: update the input value immediately
  await scheduler.postTask(() => updateInputValue(query), {
    priority: "user-blocking",
  });

  // Background: fetch and render suggestions, can be preempted
  await scheduler.postTask(
    async () => {
      const suggestions = await fetchSuggestions(query);
      renderSuggestionList(suggestions);
    },
    { priority: "background" }
  );
}

6. Slimming event handlers: debounce is not enough

A widely used but incomplete approach to improving INP is debouncing event handlers, for example on input fields. Debounce reduces the number of executions, but changes nothing about the duration of a single execution. If a single handler invocation already triggers a Long Task, that Long Task stays just as long after debouncing, just less frequent. But INP counts every single measured interaction, not the average, so debouncing only helps to a limited extent.

It is more effective to slim the event handler itself: remove expensive calculations from the synchronous path of the handler and move them into smaller, interruptible units via yielding or the Scheduler API instead. It often also helps to strictly separate the immediate visual reaction, for example highlighting a button, from the rest of the business logic, so the visual reaction happens in the first, fast phase of the handler and the expensive logic follows asynchronously afterward.

In frameworks with a virtual DOM it is also worth checking whether an interaction unnecessarily re-renders too many components at once. Selective memoization, tighter state boundaries and avoiding global state changes for local interactions reduce the amount of work that actually accrues per interaction, and thereby directly shorten the processing time within INP.

7. Presentation delay: why rendering itself affects INP

The third phase of INP, presentation delay, is frequently overlooked because it is not directly visible in the event handler code. It covers style recalculation, layout and paint after all event handlers have finished, and can be considerably lengthened by complex CSS selectors, large DOM trees or forced synchronous layouts. A handler that itself only takes ten milliseconds, but afterward causes a layout with thousands of elements to be recalculated, can still cause an INP measurement of several hundred milliseconds.

A common mistake that lengthens presentation delay is reading layout properties like offsetHeight directly after a DOM change within the same handler, which triggers a forced synchronous reflow. Such layout thrashing patterns add directly to the INP time, because the browser cannot defer the calculation to the next natural frame but has to execute it immediately.

For presentation delay it helps to batch style and layout changes instead of spreading them across multiple handlers, and to use CSS content-visibility for areas outside the visible viewport so the browser can skip their layout calculation. These measures act directly on the last, often underestimated phase of INP.

8. Measuring INP: field data, lab data and Long Animation Frames

INP can be captured both with field data from the Chrome User Experience Report and with lab data from local measurements. Field data shows the real distribution across actual users and devices, but does not reveal which specific interaction or code path is responsible. Lab data from the Performance Panel or from the Long Animation Frames API provides the necessary level of detail to attribute a concrete Long Task to a concrete script.

The Long Animation Frames API, or LoAF, was created specifically for INP diagnosis and provides additional information compared to the older Long Tasks API: which scripts ran within a long frame, how long style and layout work took, and whether a delay was caused by rendering or by pure scripting. This breakdown allows a considerably more precise prioritization of optimization measures than the mere existence of a Long Task.

// Long Animation Frames API: attributes long frames to specific scripts
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    for (const script of entry.scripts) {
      if (script.duration > 50) {
        console.warn(
          `Long script: ${script.name} took ${script.duration}ms ` +
          `(source: ${script.sourceURL})`
        );
      }
    }
  }
}).observe({ type: "long-animation-frame", buffered: true });

9. Optimization strategies compared

Not every optimization strategy for INP fits every root cause. The table below classifies the main approaches by which INP phase they primarily address and how much implementation effort they typically require.

The table shows why a pure debounce strategy is often disappointing: it only addresses the frequency of calls, not their duration, while INP measures exactly the duration of the single worst interaction. Yielding and Scheduler API prioritization act directly on the root cause and therefore deliver measurably better INP improvements for reasonable implementation effort.

10. Summary

INP forces teams to consider responsiveness across the entire session, not just the first click. Long Tasks are the most common cause of high input delay values, and yielding with a fixed chunk size is the most reliable countermeasure for making long tasks INP friendly. The Scheduler API complements yielding with real prioritization, allowing the browser itself to decide when a task should be interrupted.

It remains important to keep an eye on all three INP phases: input delay from a blocked main thread, processing time from heavy event handlers, and presentation delay from layout and paint effort. Debouncing alone does not fundamentally solve any of these problems, since it only reduces frequency. Anyone who instead works with yielding, the Scheduler API and lean handlers, and verifies results with the Long Animation Frames API, improves INP sustainably and measurably.

11. FAQ: Long Tasks and INP