Have you ever clicked a menu, selected a product filter, or pressed a form button only to wonder whether the website noticed? The page may already look fully loaded, but its controls still respond slowly. This frustrating delay is exactly the type of user-experience problem that Interaction to Next Paint is designed to measure.
Interaction to Next Paint, usually shortened to INP, is a Core Web Vitals metric that evaluates how quickly a webpage provides visual feedback after a user interaction. It observes clicks, touchscreen taps, and keyboard input throughout a page visit, helping website owners understand whether their interfaces consistently feel responsive.
A slow INP can affect almost every interactive part of a website. Navigation menus may open late, shopping carts may take too long to update, search suggestions may lag behind typing, and form submissions may appear unresponsive. Even a visually attractive website can feel broken when visitors cannot tell whether their actions have produced a result.
Improving INP requires more than making a page load faster. JavaScript execution, long main-thread tasks, inefficient event handlers, third-party scripts, large document structures, layout calculations, and complex rendering can all delay the next visual update. This guide explains how INP works and how to improve it through practical, measurable changes.
What Is Interaction to Next Paint?
Interaction to Next Paint measures the time between the beginning of a qualifying user interaction and the moment the browser presents the next visual frame. That frame might show an opened menu, a selected checkbox, an updated shopping cart, a validation message, or another visible response confirming that the interaction was processed.
INP evaluates responsiveness across the entire page visit rather than focusing only on the first action. It observes the latency of mouse clicks, touchscreen taps, and physical or onscreen keyboard input. Scrolling, hovering, zooming, and similar continuous gestures are not directly included in the metric.
For most page visits, the slowest qualifying interaction becomes the reported INP value. On highly interactive pages, the calculation discounts occasional outliers so one unusual interruption does not unfairly define the whole experience. This approach makes INP a measure of consistent responsiveness rather than an average that could hide one seriously delayed action.
A low INP indicates that a webpage can reliably respond to most user actions without noticeable delay. A high INP suggests that at least one important interaction is being blocked by JavaScript, event-processing work, style calculations, layout activity, rendering, or another task occupying the browser’s main thread.
Why Did INP Replace First Input Delay?
First Input Delay, known as FID, previously served as the Core Web Vitals responsiveness metric. FID measured how long the browser waited before it could begin processing the first user interaction. It was useful for identifying blocked main threads, but it measured only the input delay of one interaction.
FID did not include the time required to run event handlers or display the resulting visual frame. It also ignored every interaction after the first one. A page could therefore receive a good FID score even if later menus, filters, form controls, and buttons became slow during the rest of the visit.
INP provides a more complete measurement by considering interactions throughout the page lifecycle. It includes the delay before event handlers begin, the time those handlers require, and the time the browser needs to render the next frame. This broader view better reflects whether a website consistently feels responsive.
INP officially replaced FID as a Core Web Vital on March 12, 2024. The three current Core Web Vitals are LCP for loading performance, INP for responsiveness, and CLS for visual stability. Together, they evaluate whether a page loads quickly, responds promptly, and remains visually stable.
What Is a Good INP Score?
An INP of 200 milliseconds or less is considered good. A value above 200 milliseconds and up to 500 milliseconds means responsiveness needs improvement. An INP greater than 500 milliseconds is classified as poor and may produce delays that users can clearly notice.
Google recommends evaluating these thresholds at the 75th percentile of page visits, with mobile and desktop data assessed separately. This means at least 75% of measured page visits should achieve an INP of 200 milliseconds or better to provide a reliably responsive experience.
The 75th-percentile method prevents a single exceptionally fast device from hiding problems experienced by other visitors. It also avoids allowing one rare, unusually slow session to define the entire site. The result represents a level of responsiveness that most users receive or exceed.
Passing the 200-millisecond threshold should not become the only objective. A page scoring 210 milliseconds is not automatically unusable, while a page scoring 190 milliseconds may still contain a delayed checkout or navigation interaction. Website owners should combine metric thresholds with real usability testing.
Which User Actions Are Measured by INP?
INP measures three primary types of user input: mouse clicks, touchscreen taps, and keyboard presses. These actions represent many everyday website interactions, including opening menus, activating buttons, selecting filters, typing into search boxes, checking options, and navigating interactive components.
A single logical interaction may include several browser events. A touchscreen tap, for example, can trigger pointer and click events, while a keyboard action can involve keydown, keypress, and keyup events. The browser groups related events into the interaction that contributes to INP.
Scrolling, mouse hovering, pinch-to-zoom gestures, and similar continuous interactions are not directly measured as INP events. However, a control activated during or after one of these actions may still involve a qualifying click, tap, or keyboard event that becomes part of the metric.
A page may occasionally have no INP value. This can occur when a visitor reads the content without clicking, tapping, or pressing a key. It can also happen when the only activities are scrolling or hovering, because those actions are not qualifying interactions for INP.
How Is an INP Interaction Calculated?
Every measured interaction can be divided into three phases: input delay, processing duration, and presentation delay. Understanding these phases is essential because each one has different causes and requires a different optimization strategy.
Input delay begins when the user initiates an action and ends when the associated event handlers begin running. It commonly increases when another main-thread task is already executing, forcing the user’s interaction to wait in a queue.
Processing duration covers the time required for the event-handler callbacks to run. This phase may involve validating data, filtering products, updating application state, calculating totals, modifying the document, or running analytics and other secondary processes.
Presentation delay begins after the event handlers finish and ends when the browser displays the next frame. Style recalculation, layout, DOM updates, rendering, and painting can increase this phase. Chrome’s current INP diagnostics recommend identifying and reducing the slowest of these three phases first.
Why Interaction Responsiveness Matters to Users
People expect interfaces to acknowledge their actions almost immediately. When a button changes state, a menu opens, or a loading indicator appears promptly, the visitor understands that the website received the request. Without visible feedback, even a functioning application can seem frozen.
Slow interactions create uncertainty. A visitor may click the same button several times, submit a form twice, abandon a checkout, or leave the website because nothing appears to happen. These outcomes can affect usability, trust, leads, purchases, registrations, and customer satisfaction.
Responsiveness becomes especially important on mobile devices. Users may be operating the site with one hand, using a slower phone, or dealing with an unreliable connection. A delayed filter, menu, or payment control can make a mobile journey considerably more difficult than the same journey on a powerful desktop computer.
INP gives teams a measurable way to identify these problems, but its real value lies in the experiences behind the number. The goal is not merely to obtain a green report; it is to ensure that visitors receive timely, understandable feedback whenever they interact with the website.
Measure INP With Field Data First
Field data comes from real visitors using actual devices, processors, browsers, and network conditions. It can reveal slow interactions that are difficult to predict in a development environment, including problems connected to specific templates, devices, page states, or user journeys.
PageSpeed Insights presents Chrome User Experience Report data when a page or origin has enough qualifying visits. This information can show whether mobile or desktop INP is Good, Needs Improvement, or Poor over a rolling real-user measurement period.
Google Search Console groups pages with similar performance characteristics in its Core Web Vitals report. These groups can help website owners identify whether poor INP affects product pages, articles, categories, landing pages, or another shared template rather than a single isolated URL.
Field data can confirm that a responsiveness problem exists, but aggregated CrUX data cannot always reveal the exact button or interaction responsible. Real User Monitoring can provide deeper attribution, including the interaction target, interaction type, input delay, processing duration, and presentation delay.
Reproduce Slow Interactions in the Laboratory
Once field data identifies an INP problem, reproduce the affected journey in a controlled environment. Open the page, follow the same user path, and test actions such as navigation, filters, accordions, form fields, search suggestions, quantity controls, tabs, modals, and checkout buttons.
Chrome DevTools’ Performance panel can record local interactions and display an INP result. The Interactions track highlights delayed actions, while performance insights can separate the result into input delay, processing duration, and presentation delay.
Apply CPU throttling when testing because a high-powered development machine may complete JavaScript far more quickly than an ordinary mobile device. Slower CPU settings make long tasks, expensive event handlers, and rendering bottlenecks easier to reproduce and inspect.
Laboratory testing depends on the interactions you perform. A page-load audit cannot automatically discover every slow menu, filter, or checkout action. Test common user journeys and interact while the page is still loading, since script evaluation and other startup work may make early interactions particularly slow.
Identify the Exact Interaction Causing Poor INP
Do not begin INP optimization by removing random scripts or changing the whole website. First identify which element visitors interact with, what type of action they perform, when it happens, and which phase contributes most to the delay.
Real-user attribution may reveal that poor INP comes from a specific navigation button, search field, product selector, date picker, or form submission. This information helps developers reproduce the correct problem instead of optimizing unrelated parts of the page.
The visibly delayed element is not always the underlying cause. A menu may respond slowly because an analytics task is occupying the main thread, or a checkout button may be delayed by an unrelated script evaluating during page load. Examine the work occurring immediately before and during the interaction.
Prioritize interactions connected to important user journeys. A slightly slow decorative carousel may deserve less attention than a delayed Add to Cart button or payment form. Combining performance severity with business and usability importance produces a more useful optimization plan.
Reduce Input Delay by Freeing the Main Thread
Input delay occurs when an interaction must wait before its event handlers can begin. The most common reason is that the browser’s main thread is already busy running JavaScript, parsing code, calculating styles, performing layout, or handling another task.
Most JavaScript runs on the main thread, which generally handles one task at a time. A task lasting longer than 50 milliseconds is considered a long task. When several long tasks occur, user input may remain queued until the browser has an opportunity to process it.
Reduce the amount of JavaScript executed during page startup. Remove unused code, load page-specific features only where they are required, and avoid initializing every widget before the visitor can use the main interface. Smaller startup workloads leave more opportunities for early interactions.
Schedule non-essential tasks after important content and controls are usable. Analytics preparation, background calculations, recommendation generation, and other secondary work should not block navigation or form input. User-facing actions should receive priority over work the visitor cannot immediately see.
Break Long Tasks Into Smaller Tasks
A single JavaScript function may call several smaller functions, but the browser can still execute all of them as one continuous task. Dividing code into named functions improves readability, yet it does not automatically give the main thread an opportunity to process input or render a frame.
Break lengthy work into smaller tasks so the browser can respond between them. Complete the minimum work required to update the interface, allow the browser to display that change, and continue lower-priority processing afterward.
The scheduler.yield() API is designed to pause JavaScript and give the main thread an opportunity to process higher-priority work. Current guidance recommends feature detection or a fallback because the API is not supported identically across every browser.
Yielding should be deliberate rather than excessive. Pausing after every tiny operation can create unnecessary overhead. Group small jobs together, yield after meaningful batches, and prioritize the visual response the user expects before analytics, storage, or other background tasks.
Optimize Event Handlers
Event handlers should perform as little synchronous work as possible. When a visitor opens a menu, the handler should update the menu promptly rather than processing unrelated data, sending analytics, recalculating several components, and completing background work before showing the result.
Review every function called by a slow handler. A small click callback may trigger a chain of state updates, data transformations, DOM queries, rendering operations, and third-party hooks. Performance profiling can reveal work that is not obvious from the top-level function.
Avoid repeatedly performing the same calculation during an interaction. Cache values where appropriate, simplify loops, reduce unnecessary object creation, and stop processing as soon as the required result is known. Efficient logic reduces processing duration and allows the next frame to appear sooner.
Provide immediate visual feedback when a slower process cannot be avoided. Show a pressed state, progress indicator, disabled submission button, or loading message before beginning secondary work. Feedback does not eliminate the underlying processing cost, but it helps users understand that the interaction was received.
Reduce JavaScript Download and Execution Costs
JavaScript must be downloaded, parsed, compiled, and executed before many interactive features become available. A compressed bundle may appear relatively small in a network report while still creating significant processor work, especially on lower-powered mobile devices.
Remove unused libraries, duplicate packages, obsolete polyfills, and code for components that are not present on the page. Code splitting can deliver only the JavaScript required for the current route while postponing admin panels, editors, sliders, or other features until needed.
Use deferred loading for scripts that do not need to block HTML parsing. However, changing a script attribute is not a complete solution when the same large bundle still executes during a critical user interaction. Measure both download timing and main-thread execution.
Client-side rendering can increase INP when large portions of the interface must be generated or updated through JavaScript. Server-rendered or statically generated HTML can reduce startup processing, but hydration and later state updates must still be tested for responsiveness.
Control Third-Party Scripts
Third-party code can contribute substantially to poor INP. Advertising systems, analytics platforms, chat widgets, consent managers, social embeds, personalization services, and A/B testing tools may all execute on the main thread.
Audit every third-party script according to its purpose, owner, page coverage, execution cost, and business value. Remove expired experiments, duplicate trackers, unused widgets, and integrations that no longer support an active requirement.
Delay non-essential tools until after the primary interface becomes usable or until the visitor requests them. A chat application can load when its launcher is selected, while a social embed can initially appear as a lightweight preview.
Tag managers deserve careful governance because they allow new scripts to be added without a normal development release. Establish performance reviews, ownership records, and expiration dates for marketing tags so temporary campaigns do not create permanent interaction delays.
Move Suitable Work Away From the Main Thread
Some computational work does not need direct access to the webpage interface. Data processing, large calculations, parsing, sorting, encoding, and other CPU-intensive operations may be suitable for a Web Worker.
A worker executes JavaScript away from the main browser thread, allowing the interface to remain available for input and rendering. The main thread can send data to the worker and receive the completed result when the calculation finishes.
Web Workers are not suitable for every task because they cannot directly update the DOM. Moving work to a worker also introduces communication and serialization costs, so the benefit should be measured rather than assumed.
Use workers for genuinely expensive, self-contained calculations. Keep small interface updates on the main thread and avoid creating an unnecessarily complex architecture for tasks that can be optimized through simpler code or better scheduling.
Minimize DOM Size and Rendering Complexity
The browser must calculate styles and layout before it can display many interface changes. A very large Document Object Model gives the browser more elements to examine whenever an interaction updates the page.
Remove unnecessary wrappers, duplicated hidden components, unused navigation structures, and content that is rendered far before it becomes relevant. Virtualization can help applications display long lists without placing every row in the DOM simultaneously.
Be careful with broad CSS selectors and large state changes that affect substantial portions of the document. Updating one class near the top of a complex hierarchy may require the browser to reconsider styles and layout for many descendants.
Large DOM structures do not always create poor INP, but they make rendering updates more expensive. Current INP guidance recommends keeping the DOM only as large as necessary because expensive style and layout work can increase presentation delay.
Avoid Layout Thrashing
Layout thrashing occurs when JavaScript repeatedly alternates between reading layout information and changing styles or dimensions. Each read may force the browser to complete pending layout work before the next change can be applied.
For example, code may measure one element, change another element, measure again, and repeat the cycle across a long list. This pattern creates unnecessary synchronous layout calculations and can significantly delay the next frame.
Group layout reads together before performing layout writes. Store measurements, calculate the intended changes, and then update the interface in a separate step. This reduces the number of times the browser must stop and recalculate geometry.
Use Chrome DevTools to identify forced layout activity and expensive rendering tasks. Layout cost often grows with the size and complexity of the DOM, so reducing affected elements can improve both processing efficiency and presentation delay.
Reduce Presentation Delay
Presentation delay begins after event handlers finish and ends when the browser paints the next visual frame. A handler may run quickly while still producing poor INP if its DOM changes trigger expensive style, layout, rendering, or painting work.
Update only the elements that need to change. Re-rendering an entire page or large application region for a small counter, validation message, or selected state creates unnecessary work. Components should have clear boundaries that limit the scope of updates.
Avoid inserting huge blocks of HTML in response to one interaction. Creating, parsing, styling, and laying out hundreds of elements can prevent the browser from displaying immediate feedback. Render a smaller initial result and add secondary content progressively when appropriate.
Complex visual effects, large shadows, filters, and extensive paint areas may also increase rendering time. Keep important interactive transitions simple and test them on less powerful mobile devices instead of assuming desktop smoothness represents every visitor.
Improve Forms, Search, and Input Responsiveness
Forms often produce poor INP when every keystroke triggers extensive validation, calculations, network requests, or application-wide state updates. Validate only what is necessary while the visitor types and reserve more expensive checks for appropriate moments.
Debounce search suggestions, filters, and API requests so the application does not process every keystroke independently. A short, carefully selected delay can prevent duplicated requests while still making suggestions feel immediate.
Do not attach multiple event listeners that perform the same work. Review framework components, plugins, and analytics code to ensure one user action is not being processed repeatedly by overlapping systems.
Keep the visible response lightweight. Update the typed text, selected option, error state, or loading indicator first, then continue expensive filtering or server communication. The user should see evidence of the interaction before secondary work completes.
Optimize Menus, Modals, Filters, and Accordions
Interactive components should not initialize more functionality than they need. Opening a menu should not trigger a full-page rerender, load unrelated content, or recalculate every hidden navigation item.
Render frequently used components in a ready or lightweight state. If a complex modal must load data, display its shell immediately and populate the contents afterward rather than making the click appear unresponsive.
Product filters can become expensive when every selection processes a large dataset, updates the URL, sends analytics, modifies counts, and rerenders hundreds of products. Separate immediate selection feedback from the heavier results update.
Accordions and tabs should limit changes to their own content areas. Avoid global style updates or layout recalculations when a local component changes. Small, contained updates generally produce faster interaction feedback.
Improve INP in JavaScript Frameworks
Frameworks simplify component development, but they do not automatically guarantee good INP. Inefficient state management, unnecessary component renders, large hydration workloads, and complex reconciliation can still create slow interactions.
Profile the application to identify which components render after an interaction and why. Memoization may help when repeated calculations or renders are genuinely expensive, but applying it everywhere can increase complexity without delivering meaningful improvement.
Keep state as local as practical. A small input change should not rerender an entire page because its value is stored in a global context consumed by many unrelated components.
Use framework-specific performance tools together with browser profiling. The framework may reveal which components changed, while Chrome DevTools shows the actual JavaScript, style, layout, and paint costs experienced by the browser.
Improve INP on WordPress and Other CMS Websites
WordPress and other content management systems can develop INP problems through themes, page builders, plugins, sliders, popups, analytics tools, advertising scripts, and ecommerce extensions. Each feature may add event listeners and JavaScript to every page.
Begin by identifying the slow interaction and the script responsible. The total number of plugins is less useful than understanding which plugins execute expensive work during important actions.
Disable unused front-end features and prevent page-specific scripts from loading globally. A contact-form script may not be necessary on every article, while a product-gallery library may not belong on informational pages.
Test optimization changes on a staging website. JavaScript delay, script removal, or plugin replacement can break menus, forms, consent tools, tracking, and checkout functionality when implemented without careful validation.
Improve Mobile INP
Mobile users often experience poorer INP because their devices may have slower processors and less available memory. JavaScript that completes quickly on a development laptop can create long tasks on an affordable smartphone.
Use mobile field data rather than relying solely on responsive desktop emulation. Compare templates, devices, geographic regions, and user journeys to determine where slow interactions occur most frequently.
Reduce mobile interface complexity. Avoid loading desktop-only features, oversized navigation systems, hidden sliders, and unnecessary personalization code when the mobile experience does not require them.
Test on physical phones under realistic conditions. Open menus during page load, type into forms, use filters, and complete transactional actions. These practical tests can reveal delays that synthetic page-load scores do not capture.
Does INP Affect SEO?
INP is one of the three Core Web Vitals used in Google’s broader assessment of page experience. Google recommends achieving good Core Web Vitals both for search success and to provide visitors with a strong overall experience.
A good INP score does not guarantee high search rankings. Google evaluates relevance, content quality, usefulness, links, accessibility, mobile usability, security, and many other factors when determining which results to display.
INP may also support SEO indirectly by improving post-click engagement. Visitors can navigate, search, filter, register, purchase, and consume content with less frustration when controls respond promptly.
Treat responsiveness as part of a complete people-first and technical SEO strategy. Fast interactions strengthen useful content, but they cannot compensate for information that fails to answer the searcher’s question or satisfy the page’s intended purpose.
Common INP Optimization Mistakes
The first mistake is relying only on a page-load test. INP depends on user interaction, so an automated audit that simply opens a page may not reproduce the delayed button, filter, or form responsible for real-world performance.
The second mistake is treating Total Blocking Time as the same metric. TBT can provide useful laboratory clues about main-thread blocking, but it does not replace field INP or measure the complete interaction lifecycle.
The third mistake is optimizing the average interaction. INP is designed to represent the slowest or nearly slowest interaction, so several fast buttons cannot cancel out one seriously delayed checkout or navigation action.
The final mistake is removing useful features merely to obtain a lower score. The better solution is usually to load, schedule, process, and render the feature more efficiently while preserving the value it provides.
Follow This INP Improvement Workflow
Start with field data in PageSpeed Insights, Search Console, or a Real User Monitoring platform. Identify the affected templates, device category, interaction target, interaction type, and stage of the page lifecycle.
Reproduce the interaction in Chrome DevTools with realistic CPU throttling. Separate the latency into input delay, processing duration, and presentation delay, then inspect the main-thread work associated with the slowest phase.
Apply a targeted correction. Reduce startup JavaScript for input delay, simplify or split event-handler work for processing duration, and reduce DOM, style, layout, or paint work for presentation delay.
Deploy the validated change and monitor new field data. Continue testing after theme updates, plugin installations, advertising changes, marketing campaigns, and application releases because new scripts can gradually reintroduce responsiveness problems.
Practical INP Optimization Checklist
Measure real-user INP separately for mobile and desktop visitors. Identify important page templates, reproduce actual user journeys, and prioritize controls involved in navigation, forms, search, ecommerce, registration, and checkout.
Reduce long tasks by removing unnecessary JavaScript and splitting expensive work. Allow the browser to paint user-visible updates before continuing analytics, storage, calculations, and other non-critical operations.
Optimize rendering by limiting DOM size, avoiding layout thrashing, reducing broad style changes, and updating only the components affected by the interaction. Test results on slower mobile hardware.
Audit third-party code, manage tag-manager additions, and monitor INP after every major release. Sustainable responsiveness requires ongoing ownership rather than a one-time performance plugin or development sprint.
Build a Website That Responds When People Act
Interaction to Next Paint measures whether a webpage provides timely visual feedback after clicks, taps, and keyboard input. An INP of 200 milliseconds or less is considered good, while results above 500 milliseconds indicate poor responsiveness.
Improvement begins with finding the exact slow interaction. Once identified, separate its input delay, event-processing time, and presentation delay so the dominant bottleneck can be corrected directly.
Most INP improvements come from reducing main-thread pressure, breaking up long tasks, simplifying event handlers, controlling third-party JavaScript, limiting rendering work, and keeping the DOM manageable.
A responsive website feels trustworthy because people can see that their actions matter. By treating INP as a measure of human experience rather than only an SEO score, you can create interfaces that are faster, clearer, and easier to use.
Frequently Asked Questions
What does Interaction to Next Paint measure?
INP measures the time from a user’s click, tap, or keyboard input until the browser displays the next visual frame. It evaluates responsiveness throughout the page visit.
What is a good INP score?
An INP of 200 milliseconds or less is good. A score between 200 and 500 milliseconds needs improvement, while anything above 500 milliseconds is considered poor.
Is INP the same as First Input Delay?
No. FID measured only the input delay of the first interaction. INP measures the full latency of interactions across the page visit, including processing and rendering.
Why is my INP worse on mobile?
Mobile devices often have slower processors and less memory, making JavaScript, rendering, and layout work more expensive. Mobile pages may also load different menus, ads, and scripts.
How long does it take for INP improvements to appear?
Laboratory improvements may appear as soon as the fix is deployed. Field reports update gradually as new real-user visits replace older performance data.
