Interaction to Next Paint (INP): Modern Web Responsiveness for 2026 and Beyond

Mastering Interaction to Next Paint (INP): Key to Superior Web Performance and SEO

On March 12, 2024, Google officially retired First Input Delay (FID) and replaced it with Interaction to Next Paint (INP) as the responsiveness metric in Core Web Vitals. This shift marked the biggest change to how Google evaluates page experience since Core Web Vitals launched in 2020.

So what does INP actually measure? In plain terms, it captures how long it takes for a web page to visually react after a user interacts with it. When someone clicks a button, taps a menu, or presses a key, INP measures the time from that user input to the moment the browser paints the next frame that shows visual feedback. This is the new gold standard for perceived responsiveness because it reflects what users actually experience, not just what happens behind the scenes.

INP now joins Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) as the three core web vitals that influence Google search rankings. This makes it both a UX priority and an SEO concern for mid- to large-sized organizations competing for valuable keywords.

As a Toronto-based web design and development agency, we now plan, design, code, and QA every new WordPress or WooCommerce build with INP thresholds in mind from the first wireframe. The rest of this article covers what INP is, how it differs from FID, how to measure it in 2026, and modern, practical approaches to optimizing INP on real projects.

What is Interaction to Next Paint (INP)?

Interaction to Next Paint is a Core Web Vitals metric that measures how long it takes a page to visually respond to user interactions, such as clicks, taps, or key presses. Unlike metrics that focus on initial page load, INP observes all qualifying interactions throughout a page visit.

The metric reports a single INP value representing “the worst typical interaction” for that session. Specifically, it calculates the 98th percentile of interaction latencies, capturing the slowest interactions while ignoring rare extreme outliers that might skew the data.

What counts as an interaction? INP tracks mouse clicks, pointer taps on a touchscreen device, and keyboard interactions, including key presses. Passive actions like scrolling or hovering don’t qualify unless they trigger specific event handlers in your code.

Here’s where it gets nuanced: a single interaction can consist of multiple events. When a user taps a button, the browser fires pointerdown, pointerup, and click events in sequence. INP measures the full interaction latency, determined by the slowest part of that sequence across multiple event handlers.

INP breaks down each interaction into three components: input delay (the time until the browser can start processing the event), processing duration (the time spent in handlers, JavaScript, and layout work), and presentation delay (the time from finishing the work to the next paint).

This focus on “time to next paint” reflects the moment users actually see that something changed. When a user interacts with mobile navigation, they expect it to slide open. When they submit a form field, they expect to see validation feedback. The next frame is where the browser provides that initial visual feedback, and INP measures how long users wait for it.

For pages with very high interaction counts, complex SaaS dashboards or data-heavy B2B interfaces, the browser groups individual user interactions (typically 50 per segment) and drops the worst one from each group. This prevents rare catastrophic outliers from dominating the INP score while still capturing the worst interaction that represents the typical user experience.

INP vs FID: How Google’s Responsiveness Metric Evolved in 2024

First Input Delay was launched as part of Core Web Vitals in 2020 alongside LCP and CLS. After INP simmered as an experimental metric since 2022, powered by the Event Timing API, Google officially replaced FID with INP on March 12, 2024.

FID had a narrow focus: it measured only the delay before the browser began handling the very first user interaction on the page. Once the handler started executing, FID stopped measuring. And it completely ignored all subsequent interactions during the visit.

This created a significant blind spot. A page could report “good” FID numbers (under 100ms) even when later interactions were painfully slow. Think about an eCommerce site where the first interaction might be scrolling or clicking a simple link, but applying filters on a product listing or submitting a quote form takes several seconds. FID would miss these slow interactions entirely.

INP addresses this by measuring the entire interaction lifecycle that includes input delay, processing time, and presentation delay for all the interactions throughout the visit, not just the first one. When a user initiates any qualifying interaction, INP captures the full latency to visual feedback.

What changed in Google tooling in 2024? FID was removed from the Core Web Vitals report in Google Search Console as of March 2024. PageSpeed Insights, CrUX, and Lighthouse dashboards now highlight INP instead of FID. Any old FID guidance should now be interpreted through the lens of INP.

This Parachute Design article absorbs and replaces our legacy FID guidance. If your site used to “pass” FID but now fails INP, it’s because Google is finally looking at what your users actually experience after the first interaction and across the full session.

What is a Good INP Score in 2026?

Google’s official thresholds classify INP scores as: Good (INP ≤ 200 ms), Needs Improvement (200–500 ms), and Poor (> 500 ms).

Google evaluates INP at the 75th percentile of page loads, separately for mobile and desktop devices, based on real user data from Chrome users over the last 28 days. This data comes from the Chrome User Experience Report (CrUX).

What does this mean practically? A page with an INP of 260 ms at the 75th percentile on mobile means that one in four visits still experiences worse latency than that. Poor INP scores indicate a significant portion of your users are experiencing frustrating interaction delays.

Mobile is often the bottleneck. On constrained 4G-like networks with mid-range device capabilities, heavy JavaScript frameworks, large DOMs, and third-party scripts push INP up faster than on desktop devices. CrUX data show that median mobile INPs frequently hover near 300ms for unoptimized sites, versus sub-150ms on desktop.

For new projects, we recommend setting internal performance budgets: aim for less than 150ms INP for core marketing and lead-gen pages, and ensure key transactional journeys (eCommerce checkout, intake forms) consistently stay under 200ms on mobile.

Monitor INP trends over time rather than reacting to a single test. CrUX aggregates data over 28 days, and seasonal traffic shifts can move the needle. A good INP score requires consistent performance across varied real-world conditions, not just optimal lab results.

How Interaction to Next Paint is Measured

INP is fundamentally a field metric derived from real user interactions via the Event Timing API. However, once issues are identified, lab tools become essential for diagnosis and debugging.

INP observations are generated in the browser on each page view and surfaced through tools such as Chrome User Experience Report (CrUX), PageSpeed Insights, Google Search Console’s Core Web Vitals report, and Real User Monitoring (RUM) libraries, including the web-vitals.js library integrated directly into a site.

Unlike lab metrics such as Total Blocking Time (TBT), you cannot meaningfully measure INP without genuine user interactions or scripted flows that mimic them. Lab data alone won’t give you INP; you need real user data or carefully constructed test scripts.

For single-page applications and custom WordPress front-ends, the Event Timing API tracks interactions across the page’s life, not just at initial page load. This is especially important for dashboards, configurators, and search-page interfaces, where most interactions occur after the page has loaded.

Some synthetic tools may show “No INP” or “Not enough data” if no measurable interactions happened during the test or in the real-world sample, or if traffic volume is too low for CrUX to report a statistically significant percentile.

For high-value B2B or eCommerce experiences, we recommend instrumenting first-party RUM on your own domains. This lets you see exactly which components and templates are hurting INP with contextual data, not just top-line numbers.

Field Measurement: CrUX, PageSpeed Insights and RUM

Chrome User Experience Report (CrUX) aggregates anonymized INP data from real Chrome users and exposes it via BigQuery and PageSpeed Insights. This real user data reflects actual device capabilities and network conditions your visitors experience.

In PageSpeed Insights, the INP value appears in the Core Web Vitals assessment section. It represents the 75th percentile over the last 28 days. When traffic for a specific page is low, you’ll see “Origin” data (aggregated across your entire domain) rather than “This URL” data.

Google Search Console’s Core Web Vitals report provides site-wide visibility. It groups related URLs by issues such as “INP issue: longer than 200 ms (mobile),” helping you prioritize which templates need attention—for example, determining whether your blog or product template is the primary culprit.

For ongoing monitoring, implement Real User Monitoring with the official Web Vitals library. Use the onINP callback to capture per-interaction data, including latency, target selector, and interaction type. Send this data to your analytics or data warehouse to continuously monitor INP and attribute INP issues to specific components.

From Parachute’s perspective, we integrate RUM into new WordPress and WooCommerce builds for enterprise clients. This transforms web performance from a one-time launch check into a continuous KPI that informs ongoing optimization.

Lab Investigation: DevTools, Lighthouse, TBT and LoAF

While INP itself is field-focused, lab tools are essential for reproducing problematic interactions and identifying root causes. You can’t fix what you can’t diagnose.

Chrome DevTools Performance panel is your primary diagnostic tool. Record a session while clicking and typing through key flows, navigation menu, filters, add-to-cart, and form submission. Look at the “Interactions” lane to locate slow blocks and correlate them with main thread activity in the flame chart.

Total Blocking Time (TBT) in Lighthouse and other lab tools acts as a proxy for INP during development. High TBT during interaction-heavy phases usually correlates with poor INP in the field. Long tasks that block the main thread for more than 50ms contribute to TBT and typically cause interaction delays. Optimizations that lower TBT generally improve INP as well.

The Long Animation Frames (LoAF) API helps identify long frames that cause rendering delays during interactions. RUM and performance monitoring tools can use LoAF to attribute these delays to specific scripts or components, providing you with actionable data on which code samples are responsible.

Build repeatable lab scripts for critical user journeys, step-by-step checkout, lead form completion, and product configurator flows. This allows you to catch INP regressions in CI/CD pipelines before they reach production and affect real users.

Modern Strategies to Improve INP

Improving INP centers on three goals: keeping the main thread free, keeping event handlers lean, and rendering only what’s necessary as quickly as possible. These principles apply whether you’re building with React, Vue, Next.js, headless WordPress, or WooCommerce with heavy plugins.

Modern frontend stacks can all achieve excellent INP if they’re architected carefully around performance budgets. The key is making INP a first-class concern, not an afterthought.

For Parachute Design projects, INP optimization is baked into: UX wireframes (minimizing unnecessary interaction complexity), UI design (avoiding gratuitous animation on core flows), engineering (code-splitting, lazy loading, careful use of third-party scripts), and QA (field and lab tests to validate that INP meets or beats 200ms thresholds).

The three big levers are: reducing input delay, reducing processing time in handlers, and reducing presentation delay.

1. Reduce Input Delay: Free Up the Main Thread

Input delay increases when the main thread is busy with other work at the time of the interaction. Heavy JavaScript execution, large JSON parsing, and complex layout calculations all block the thread and delay the browser’s response to user input.

Practical strategies to reduce input delay:

• Break up long tasks into smaller chunks using requestIdleCallback, setTimeout, or scheduler APIs so the browser can quickly respond to input between work chunks
• Defer non-critical JavaScript (analytics, heatmaps, carousels in the footer, marketing popups) until after initial interaction windows have passed
• Use code-splitting and tree-shaking so that interaction-critical routes load as little JavaScript as possible by default

For WordPress or WooCommerce sites, audit plugins for unnecessary scripts loading globally. Remove unused plugins entirely. Load heavy scripts conditionally only on templates that need them—for example, a product configurator script should load on product pages, not on blog posts.

Target mobile conditions explicitly during testing. Test with CPU and network throttling resembling mid-tier Android devices on 4G to expose input delay problems early. Mobile INP is often the limiting factor in CrUX data, so optimizing for constrained conditions pays dividends.

2. Reduce Event Processing Time: Keep Handlers Lean

Event processing time is the time spent inside the callbacks associated with an interaction. This is where most application logic lives in modern frameworks, and it’s often where slow interactions originate.

Best practices for optimizing event handlers:

• Keep interaction handlers focused on essential UI work (state changes, minimal DOM updates); defer analytics, logging, and secondary operations to later microtasks
• Avoid performing expensive computations (complex filtering, large data transforms) in direct response to every keystroke or click; debounce or throttle where possible
• Use framework features like React’s concurrent rendering or memoization (React.memo, useMemo, useCallback) to avoid unnecessary re-renders during interactions

Global event listeners deserve special attention. Audit catch-all document or window listeners from analytics, A/B testing, or third-party widgets that fire on every click or keydown. These can add significant processing duration to every interaction. Remove or narrow their scope when they meaningfully affect interaction latency.

For WordPress and WooCommerce builds, replace heavy jQuery-era interaction patterns with modern, vanilla JavaScript or lightweight alternatives. Avoid stacking multiple overlapping plugins that hook into the same events—several form helper or tracking plugins all firing on the same submit button can create compounding delays.

3. Reduce Presentation Delay: Render Efficiently

Presentation delay is the time between finishing the work for an interaction and when the next frame with visual feedback is painted to the screen. Even if your handlers are fast, slow rendering can still hurt INP.

Techniques to cut presentation delay:

• Minimize DOM complexity, especially inside UI elements that update frequently (navigation menus, accordions, filters)
• Use CSS content-visibility and lazy loading to avoid painting large offscreen sections until needed
• Avoid synchronous layout thrashing: batch DOM reads and writes instead of interleaving them in a single handler, which forces the browser to recalculate layout repeatedly

Prioritize “where the user is looking.” For menus, modals, and forms, focus on getting the core state change visible immediately—show the modal shell or backdrop first—and progressively enhance secondary content afterward. Defer non-critical animations and decorative transitions until after the core content is visible and reliably responsive.

Design-level decisions support good INP, too. Prefer simple, direct UI transitions for mission-critical actions like checkout, booking, or quote requests. Use motion sparingly and purposefully, ensuring CSS animations and transitions don’t block painting. Built-in browser controls often outperform custom JavaScript implementations for basic interactions.

Diagnosing Slow INP on Real Projects

When an INP issue appears in Google Search Console or PageSpeed Insights, you need a systematic diagnostic approach. Here’s the process we recommend for agencies, in-house teams, and product owners.

Step 1: Identify which templates or journeys are impacted using Search Console groupings. Are product pages the problem? The checkout flow? A specific landing page template?

Step 2: Reproduce the problematic interactions manually while profiling in Chrome DevTools. Enable CPU throttling to simulate mobile conditions and record performance while clicking through the suspect flows.

Step 3: Correlate slow interaction blocks with specific scripts, components, or plugins. The Performance panel’s flame chart shows exactly which functions consumed time during each interaction.

Step 4: Ship targeted fixes as separate tasks, then monitor INP over the next 28 days in CrUX and GSC to validate improvements.

Common culprits to check first:

• Heavy client-side routing and state management in SPAs
• Overly complex mega-menus or navigation built entirely in JavaScript
• All-in-one marketing scripts (tag managers, A/B test suites) attached to every click
• Overloaded WooCommerce product pages with multiple recommendation engines, review widgets, and tracking pixels

For redesign projects, we often start with a Core Web Vitals audit comparing INP between legacy templates and modernized designs. This ties tangible improvements to business outcomes like form completions and e-commerce conversion rates.

INP, SEO and Business Outcomes

As of March 12, 2024, INP is an official core web vital metric and therefore a direct input into Google’s page experience signals for ranking. It sits alongside other core web vitals (LCP and CLS) as part of the broader search page quality assessment.

While INP alone won’t make or break rankings, consistently poor INP on high-value pages—product detail, pricing, signup—can compound other performance and UX issues. This makes it harder to compete for lucrative keywords, especially against competitors who have invested in a reliably responsive web page experience.

The connection to business KPIs is direct: faster, more reliable interactions reduce form abandonment and checkout drop-off. Improved INP often correlates with better engagement with complex tools such as configurators, calculators, and search interfaces. When users get immediate visual feedback, they’re more confident that the interface is working and more likely to complete their intended action.

Public case studies from various eCommerce optimizations report 10-20% conversion lifts from achieving sub-200ms INP. This reinforces that INP is not just a “technical metric” but a business lever that affects revenue.

Parachute Design’s services are built around this understanding: custom WordPress and WooCommerce builds engineered around Core Web Vitals budgets, UX and UI strategy that balances aesthetics with web performance, and ongoing performance maintenance retainers to continuously monitor INP and other vitals as content and technology stacks evolve.

For decision-makers, treat INP as part of a broader digital brand experience. A fast, responsive interface communicates professionalism and care in ways that align with premium B2B positioning. When a web page’s responsiveness matches the quality of your products and services, the entire brand experience feels cohesive.

Bringing It Together: How We Design for INP from Day One

The key conceptual points: INP measures the time from interaction to visible feedback across the full visit. It replaced FID in 2024 because it more accurately reflects the real user experience across multiple interactions, not just the first. A good INP score (≤ 200 ms at the 75th percentile) requires coordinated design and engineering decisions from project kickoff through launch.

A professional agency should operationalize INP throughout its workflow:

Phase	INP Considerations
Discovery & UX	Map key interactions and define performance budgets per journey
Design	Create interaction models and motion systems that are visually rich but technically efficient
Development	Performance-conscious component architecture, code-splitting, and minimal use of third-party scripts
QA & Launch	Combine lab tools (Lighthouse, DevTools) with early RUM to validate INP before and after go-live

For clients investing in a new website or eCommerce platform, INP and overall Core Web Vitals performance are not optional extras but foundational quality criteria. This is the baseline for a page’s responsiveness in 2026 and beyond.

If you’re seeing “INP longer than 200 ms” warnings in Search Console or planning a redesign because your website was built before 2024, now is the time to optimize interaction performance. We offer performance-focused audits and consultations that align UX, branding, and Core Web Vitals into a single strategic roadmap—ensuring your next web project delivers both the visual impact and the technical excellence your organization deserves.