Interaction to Next Paint (INP) Explained

Interaction to Next Paint (INP) is a Core Web Vital that measures how responsive a web page is to user interactions. It evaluates how long the browser takes to produce the next visual update after a user interacts with the page, helping identify interfaces that feel slow or unresponsive.

A page can load quickly and still provide a poor experience if buttons, menus, forms or other controls respond slowly. INP focuses on this part of the user experience by examining interactions such as clicks, taps and keyboard input throughout a page visit.

Poor INP is commonly associated with excessive JavaScript, long tasks, expensive event handlers, large DOM updates and other work that keeps the browser's main thread busy. Improving INP therefore usually involves reducing unnecessary work and making interaction processing more efficient.

What Is Interaction to Next Paint?

Interaction to Next Paint measures the latency of user interactions with a web page. When a user clicks a button, taps a control or presses a key, the browser must process the event and perform the work required to update the interface. INP measures the delay until the next visual update can be presented.

The metric is designed to represent overall interaction responsiveness rather than the speed of a single predefined action. During a page visit, users can perform many interactions, and INP considers the interaction latency that best represents the slower end of the experience.

Why INP Matters

Responsiveness strongly affects how an interface feels. Users expect buttons, menus, search fields, dialogs and other controls to react quickly after input. Even when the page has already loaded, long delays can make the application appear broken or unreliable.

• Measures responsiveness during real interactions.
• Helps identify JavaScript performance problems.
• Reveals long tasks blocking the main thread.
• Provides a measurable target for interaction latency.
• Complements loading and visual stability metrics.

INP vs Other Core Web Vitals

INP measures a different aspect of performance than Largest Contentful Paint and Cumulative Layout Shift. LCP focuses on loading the main visible content, CLS measures unexpected layout movement, and INP focuses on how quickly the interface responds to user input.

How a Browser Processes an Interaction

When a user interacts with a page, the browser must receive the input, dispatch the appropriate event, execute application code, update the document and render the resulting visual change. If the main thread is already busy, the interaction may have to wait before its work can begin.

User interaction
       ↓
Input received
       ↓
Event processing
       ↓
JavaScript execution
       ↓
DOM/style updates
       ↓
Layout and rendering
       ↓
Next visual update

INP is affected by delays throughout this process. A short event handler can still result in a slow interaction if the browser is blocked by another long task before the handler starts or if the resulting DOM update requires expensive rendering work.

The Three Parts of Interaction Latency

An interaction can be understood as three broad stages: input delay, processing time and presentation delay. Looking at these stages helps developers determine where an interaction is spending its time.

Input Delay

Input delay occurs when the browser cannot immediately process an interaction because the main thread is occupied with other work. A user may click a button while JavaScript is executing a long task, forcing the browser to wait before it can handle the new input.

This means that reducing long tasks is one of the most important strategies for improving responsiveness. Even code unrelated to the interaction can contribute to its latency if it occupies the main thread at the wrong time.

Processing Time

Processing time represents the work performed in response to the interaction. This may include JavaScript event handlers, state updates, DOM manipulation, validation, calculations or other application logic.

• Event handler execution.
• State updates.
• DOM manipulation.
• Form validation.
• Data processing.
• Filtering or sorting large datasets.
• Application-level calculations.

Presentation Delay

After JavaScript has completed its work, the browser may still need to calculate styles, perform layout, paint content and prepare the next visual update. Complex interfaces can require substantial rendering work, adding additional latency after the event handler has finished.

For this reason, optimizing only the JavaScript function attached to a button may not be enough. Developers should also consider the size of the DOM update and the rendering work caused by the interaction.

What Causes Poor INP?

The most common cause of poor INP is excessive main-thread work. JavaScript is a major contributor, but rendering, layout and other browser tasks can also prevent the interface from responding quickly.

• Long JavaScript tasks.
• Large JavaScript bundles.
• Expensive event handlers.
• Large DOM updates.
• Complex style calculations.
• Heavy layout operations.
• Large client-side application state updates.
• Third-party scripts.
• Expensive synchronous calculations.
• Unnecessary work triggered by interactions.

Long Tasks and INP

A long task is a piece of work that occupies the browser's main thread for an extended period. While a long task is running, the browser has fewer opportunities to respond to user input or update the screen.

Long JavaScript task
        ↓
Main thread remains busy
        ↓
User clicks a button
        ↓
Interaction waits
        ↓
Event handler executes
        ↓
Visual update appears later

Long tasks can therefore create input delay even when the interaction handler itself is relatively efficient. Reducing or splitting long tasks can improve responsiveness across many interactions.

How JavaScript Affects INP

JavaScript is often the most important factor when investigating a poor INP score. Framework code, application logic, third-party libraries and event handlers all execute on the main thread unless work is explicitly moved elsewhere.

• Reduce unnecessary JavaScript.
• Remove unused dependencies.
• Split large bundles.
• Defer non-critical functionality.
• Avoid expensive synchronous calculations.
• Keep event handlers focused.
• Reduce unnecessary state updates.
• Limit third-party scripts.

Large JavaScript Bundles

Large JavaScript bundles can increase the amount of work required during page initialization and interaction. The browser must download, parse and execute JavaScript, and some of this work can compete with user input for main-thread time.

Code splitting and lazy loading can reduce the amount of JavaScript required upfront. However, interactive features should still load in time for the user to interact with them without introducing new delays.

Event Handler Optimization

Event handlers should perform only the work necessary to process the interaction. Expensive calculations, unnecessary DOM operations and unrelated application updates can make otherwise simple controls feel slow.

button.addEventListener("click", () => {
  updateUI();
  calculateLargeDataset();
  rebuildLargeList();
  processUnrelatedData();
});

A better design separates immediate interface updates from work that does not need to happen before the user sees the response. Expensive operations can sometimes be deferred, scheduled or performed incrementally.

Breaking Up Long Tasks

One large task can prevent the browser from responding to input for its entire duration. Breaking expensive work into smaller pieces gives the browser more opportunities to process user interactions and update the screen.

function processItems(items) {
  const chunk = items.splice(0, 100);

  processChunk(chunk);

  if (items.length > 0) {
    setTimeout(() => {
      processItems(items);
    }, 0);
  }
}

The exact scheduling technique depends on the application. The goal is to avoid monopolizing the main thread with large uninterrupted operations.

DOM Size and INP

Large and complex DOM structures can increase the amount of work required when an interaction changes the interface. Updating a small component is generally easier for the browser to process than repeatedly modifying a huge portion of the document.

• Avoid unnecessarily large DOM trees.
• Update only the elements that need to change.
• Avoid rebuilding large lists unnecessarily.
• Use efficient rendering strategies for large datasets.
• Keep interactive components reasonably isolated.

Layout and Rendering Work

An interaction can trigger style recalculation, layout and painting. Changing properties that affect geometry may require more browser work than changing properties that can be composited efficiently.

For animations and visual transitions, properties such as transform and opacity are often preferable because they can reduce expensive layout work when used appropriately.

Third-Party Scripts and INP

Third-party scripts can execute code independently of the application's own interface. Analytics, advertising, embedded widgets, chat systems and other integrations may consume CPU time and occupy the main thread.

INP in Single-Page Applications

Single-page applications can have complex interaction patterns because navigation, state management and rendering often happen entirely in the browser. A single click can trigger multiple state changes, data processing operations and component renders.

Frameworks can help organize this work, but they do not automatically guarantee good INP. Developers still need to avoid unnecessary renders, expensive calculations and large synchronous updates.

INP and React Applications

In React applications, unnecessary component renders, expensive calculations and large state updates can contribute to interaction latency. A button click that updates a high-level state value may cause more components to render than necessary.

• Keep state as local as practical.
• Avoid unnecessary parent-level state updates.
• Memoize expensive calculations when appropriate.
• Avoid rendering unnecessarily large lists.
• Virtualize very large collections when appropriate.
• Keep event handlers lightweight.
• Measure before adding optimization techniques.

Forms and INP

Forms can produce interaction performance problems when every keystroke triggers expensive validation, filtering, rendering or network-related work. This is especially noticeable in large forms or interfaces with complex derived state.

• Avoid expensive work on every keystroke.
• Debounce operations that do not need immediate execution.
• Validate only the necessary fields.
• Avoid rerendering unrelated form controls.
• Defer non-critical processing.

Search and Filtering Interfaces

Search boxes, filters and sorting controls can become expensive when every input immediately processes a large dataset. Filtering thousands of records synchronously after every keystroke can block the main thread and increase interaction latency.

Depending on the application, developers can reduce the amount of data processed, debounce input, paginate results, use more efficient algorithms or move expensive computation away from the main thread.

Web Workers and INP

Web Workers can perform suitable CPU-intensive JavaScript away from the main browser thread. This can be useful for applications that need to process large datasets, perform calculations or transform data without blocking user interactions.

const worker = new Worker("/worker.js");

worker.postMessage(data);

worker.onmessage = (event) => {
  updateUI(event.data);
};

Workers are not a universal solution. Communication between the worker and the main thread has overhead, and DOM manipulation still needs to occur on the main thread. They are most useful when significant CPU-bound computation can be separated from interface work.

Network Requests and INP

A network request itself does not necessarily make an interaction slow, but the JavaScript work surrounding the request can. An interface may wait for a response and then perform expensive processing, render a large result set or execute multiple updates.

For interactive features, it is often useful to provide immediate visual feedback before waiting for the network operation to complete. The interface can indicate that an action has started while more expensive processing happens asynchronously.

Caching and INP

Caching can indirectly improve responsiveness by reducing network work and allowing applications to retrieve frequently used resources or data more quickly. However, caching alone does not fix CPU-bound JavaScript or expensive rendering.

How to Diagnose Poor INP

The most useful approach is to identify the interaction responsible for the poor experience and inspect the browser's main-thread activity around that interaction. Look for long tasks before the event, expensive event handlers and large rendering updates afterward.

• Identify the slow interaction.
• Check whether input is waiting behind another task.
• Measure the event handler duration.
• Inspect JavaScript execution.
• Look for expensive DOM updates.
• Check style and layout work.
• Identify third-party activity.
• Test the interaction on representative hardware.

A Practical INP Optimization Workflow

Measure INP
    ↓
Identify slow interaction
    ↓
Check input delay
    ↓
Check event handler
    ↓
Check rendering work
    ↓
Reduce main-thread work
    ↓
Test again
    ↓
Monitor real users

Laboratory Testing vs Real User Data

Laboratory testing is useful for reproducing interaction problems and examining browser activity in a controlled environment. Real-user data is important because interaction performance depends heavily on the device and software environment used by visitors.

A desktop computer with a powerful processor may process JavaScript much faster than an average mobile device. An interaction that feels instant during development can therefore become noticeably slower for real users.

Common INP Optimization Mistakes

• Focusing only on initial page load.
• Ignoring long tasks unrelated to the failing interaction.
• Optimizing code without measuring the actual bottleneck.
• Adding excessive memoization without evidence.
• Updating large parts of the DOM unnecessarily.
• Running expensive calculations synchronously.
• Ignoring third-party scripts.
• Testing only on high-end desktop hardware.
• Assuming asynchronous code cannot affect responsiveness.
• Trying to solve CPU-heavy work with caching alone.

INP Optimization Checklist

• Keep JavaScript execution lightweight.
• Break up long tasks.
• Keep event handlers focused.
• Avoid unnecessary DOM updates.
• Reduce expensive style and layout work.
• Optimize large lists and datasets.
• Debounce expensive input operations when appropriate.
• Defer non-critical work.
• Use Web Workers for suitable CPU-intensive tasks.
• Limit third-party JavaScript.
• Avoid unnecessary application-wide state updates.
• Test on realistic mobile hardware.
• Measure both laboratory and real-user performance.

INP and JavaScript Minification

Minifying JavaScript reduces the size of downloaded files, which can improve transfer and parsing costs. However, minification alone rarely solves a serious INP problem. If an application performs expensive calculations or unnecessary rendering, making the code smaller does not remove the underlying work.

For INP, reducing unnecessary JavaScript and execution time is generally more important than simply reducing the number of characters in the source code.

INP and CSS Optimization

CSS can influence interaction responsiveness when an interaction causes significant style recalculation or layout work. Keeping styles efficient and avoiding unnecessary geometry changes can reduce the amount of rendering work required after an interaction.

CSS minification is useful for reducing stylesheet transfer size, but developers should also examine how CSS changes affect layout and rendering during interactive states.

Frequently Asked Questions

Helpful Performance Tools

A JS Minifier can reduce JavaScript file size, a CSS Minifier can compress stylesheets, and an HTML Minifier can reduce unnecessary HTML characters. An HTTP Request Builder can help construct and inspect HTTP requests during development, while a Cache-Control Generator can help create cache directives for HTTP resources.

Conclusion

Interaction to Next Paint measures an important part of web performance that traditional page-load metrics cannot fully describe: how quickly a page responds when users interact with it. A fast initial render is not enough if buttons, forms, menus and other controls remain unresponsive for noticeable periods.

The most effective INP improvements come from reducing main-thread work. Breaking up long tasks, keeping event handlers lightweight, limiting unnecessary JavaScript, reducing expensive DOM updates and managing third-party scripts can make interfaces significantly more responsive.

INP should be optimized through measurement rather than assumptions. Identify the slow interaction, determine whether the delay comes from input waiting, event processing or presentation work, apply a targeted optimization and measure again. Combining laboratory diagnostics with real-user data provides the clearest picture of how responsive a website actually feels.