Interaction to Next Paint (INP) optimization: thresholds, diagnosis and fixes for slow interactions

What is Interaction to Next Paint, and why does it matter for SEO?

Interaction to Next Paint, usually shortened to INP, is the Core Web Vital for responsiveness. It observes the latency of every click, tap and keyboard interaction during a visit and reports a single value that nearly all interactions fall beneath. A low INP means the page feels instant, and a high one means taps seem ignored.

How does Google define INP?

Google's web.dev guidance, last updated September 2, 2025, describes INP as a stable Core Web Vital that assesses a page's overall responsiveness. The value is the worst interaction latency, ignoring one outlier for every 50 interactions, and the figure judged for a page is the 75th percentile of page views, segmented by mobile and desktop. INP is the successor to First Input Delay (FID), which looked only at the first interaction's input delay, and INP took over as the responsiveness Core Web Vital in March 2024.

Which interactions count toward INP?

Only clicks, taps and key presses. Scrolling, hovering and zooming are not observed, because they are handled differently by the browser and do not wait on page scripts in the same way.

Does INP affect rankings?

Google's page experience guidance says its core ranking systems seek content that provides a good page experience, and Core Web Vitals are part of how it describes that. Google also says that good scores do not guarantee top rankings, because relevance and content quality dominate. Treat INP as a user-experience requirement with a modest, supporting role in search, and as a direct driver of conversions, since slow interfaces lose customers regardless of rankings. The broader context lives in the guide to Core Web Vitals and how they relate to rankings.

Why do business owners care beyond search?

Because a laggy add-to-cart button, a slow mobile menu or a form that freezes loses sales. INP measures the thing visitors feel most.

How does INP differ from the other Core Web Vitals?

Metric	What it measures	Typical culprit
Largest Contentful Paint (LCP)	How fast the main content appears	Slow server, heavy hero image, render-blocking resources
Interaction to Next Paint (INP)	How fast the page responds to input	Long JavaScript tasks, heavy handlers, large DOM
Cumulative Layout Shift (CLS)	How stable the layout is	Images without dimensions, late-loading ads and fonts

Can a page pass LCP and still fail INP?

Yes. A page can paint quickly and then freeze while scripts hydrate. That gap is why INP became its own metric.

What are the INP thresholds, and how is the value measured?

INP is rated good at 200 milliseconds or less, needs improvement above 200 and up to 500 milliseconds, and is poor above 500 milliseconds, evaluated at the 75th percentile of page views. In other words, three out of four visits should respond within the good threshold.

What does the 75th percentile mean in practice?

If a page has 100 visits, sort them by their INP value. The 75th visit's value is the number that counts. A handful of very slow visits will not fail the page, but a quarter of slow visits will. Mobile and desktop are assessed separately, so a desktop pass can hide a mobile failure.

Why is mobile usually worse?

Phones have slower processors and less memory, so the same JavaScript takes longer to run. Test on real mid-range devices, not only on a fast laptop.

What is the difference between field data and lab data?

Field data comes from real users, collected through the Chrome User Experience Report or your own real user monitoring, and it reflects actual devices, networks and behavior. Lab data comes from controlled tests, such as Lighthouse or DevTools, and depends on the interactions you script. Google recommends field measurement as the preferred approach, and notes that Total Blocking Time can act as a lab proxy but is not a substitute for INP.

Where do you find field INP?

PageSpeed Insights shows Chrome User Experience Report data at origin level and sometimes URL level. Search Console's Core Web Vitals report groups URLs by status, and a real user monitoring script using the web-vitals library's onINP function can report values from your own visitors, including which element caused the slow interaction.

How do you find the interaction that causes a poor score?

Real user monitoring that records the interaction target and type is the fastest route. In the lab, open Chrome DevTools, record a performance trace while you click, tap and type through key flows, and inspect the interactions track. Lighthouse timespan mode can measure a specific sequence. Interact during page load as well, because that is when the main thread is busiest.

What if lab and field values disagree?

Trust the field. Real users trigger interactions you did not test, on devices you did not use. Use the lab to reproduce and fix the problem the field data reveals.

What happens during an interaction, and which phase is slow?

Every interaction passes through three phases: input delay, processing duration and presentation delay. INP is the sum of the three, so diagnosis starts with finding which one dominates.

What is input delay?

Input delay is the time between the user's action and the moment event handlers begin to run. It is long when the main thread is busy with something else, such as a long task started by a script, a timer, a hydration step or an analytics tag. The page cannot respond until the current task yields.

How do you reduce input delay?

Break long tasks into smaller chunks, defer non-essential scripts until after the page becomes interactive, remove or delay third-party tags and avoid starting heavy work in response to load events. The less the main thread does at idle, the sooner it can answer a tap.

What is processing duration?

Processing duration is the time spent running your event handlers. A click handler that filters a large list, recalculates prices, updates the whole page state or runs synchronous layout reads can take hundreds of milliseconds.

How do you shorten handlers?

Do the minimum work needed to show feedback, then defer the rest. Update the visible state first, and push heavy computation, network calls and analytics to later tasks. Avoid forcing layout in loops by reading and writing DOM properties in separate batches.

What is presentation delay?

Presentation delay is the time from the end of the handlers until the browser paints the next frame. It grows when the page has a very large DOM, complex CSS selectors, expensive style recalculation, layout thrashing or heavy rendering work such as large animated areas.

How do you reduce presentation delay?

Keep the DOM small, limit the area that must be re-laid out after an interaction, use CSS containment and content-visibility for off-screen sections and avoid animations that trigger layout. A smaller render tree paints faster.

What typically causes a poor INP on real websites?

Poor INP usually comes from too much JavaScript running on the main thread, especially from frameworks, tag managers, widgets and plugins. The cause is rarely one script. It is the accumulated weight of many.

Which patterns show up most often?

• Heavy framework hydration: a server-rendered page that must load and execute a large bundle before it responds.
• Third-party scripts: chat widgets, A/B testing tools, ad tags, consent managers and analytics that hold the main thread.
• Large DOMs: thousands of nodes from long lists, mega menus and page builders.
• Expensive handlers: filters, sorting, carousels and price calculators that do synchronous work on every tap.
• Layout thrashing: repeated reads and writes of layout properties inside loops.
• Long tasks at load: startup work that overlaps the first interactions.

Which pages are the most exposed?

Pages with rich interactivity: ecommerce category pages with filters, product pages with variant selectors, checkout flows, booking forms and any page built with a heavy front-end framework.

How do ecommerce filters and variant pickers hurt INP?

Filtering a large product grid on the client often re-renders hundreds of nodes and runs many state updates. Variant selectors recalculate price, stock and images synchronously. The result is a tap that lags. The patterns in the guide to JavaScript-based filters and content visibility describe how the same code that hides content from crawlers can also slow users down.

What helps most for filters?

Render the first view on the server, update only the changed part of the grid, debounce text input, paginate results and avoid recomputing everything on each click.

How do apps, plugins and themes contribute?

Every installed app or plugin adds code. On hosted platforms, a dozen apps can add hundreds of kilobytes of scripts that run on every page. The breakdown of how Shopify apps affect blocking time and Core Web Vitals shows how to measure and remove the worst offenders.

How do you decide which app to remove?

Measure each one: disable it on a test copy, compare total blocking time and INP in a trace and weigh the result against the revenue or function the app provides.

How do you break up long tasks and keep the main thread free?

A long task is any task that blocks the main thread for more than 50 milliseconds. Breaking long tasks into smaller pieces lets the browser handle user input between them, which directly reduces input delay and often processing duration.

Which techniques split long tasks?

Yield to the main thread between chunks of work, using the scheduler's yield method where it is available, or falling back to a short timeout. Process large arrays in batches. Move heavy computation to a web worker so that it never touches the main thread. Defer non-critical initialization with idle callbacks. Prioritize the work that produces visible feedback.

What does yielding look like in practice?

async function processItems(items) {
  for (let i = 0; i < items.length; i++) {
    handle(items[i]);
    // Let the browser handle input and paint every few items
    if (i % 50 === 0) {
      await (self.scheduler?.yield ? scheduler.yield() : new Promise(r => setTimeout(r)));
    }
  }
}

The sample is illustrative. Adjust the batch size to your workload, and measure the result in a performance trace.

How do you keep event handlers light?

Give immediate visual feedback first, such as a pressed state or spinner, then run heavy work after the next paint. Debounce high-frequency events such as typing in a search box. Use passive listeners for touch and wheel events where appropriate, and remove listeners you no longer need.

Should every handler be asynchronous?

No. Make a handler asynchronous only when it does enough work to delay the next frame. Simple state changes are fine as they are.

How do web workers help?

A web worker runs scripts on a separate thread, so heavy parsing, sorting, search indexing or data transformation does not block taps. Workers cannot touch the DOM directly, so pass data in and render the result on the main thread. They suit computation, not UI updates.

What are the limits of workers?

Messaging has a cost, and data copying can erase the gain for small tasks. Use workers for work that takes tens of milliseconds or more.

How do you ship less JavaScript and defer what is not needed?

The fastest script is the one you never send. Reducing the amount of JavaScript that loads and runs on each page lowers startup cost, shortens long tasks and frees the main thread for real interactions.

What reduces JavaScript weight?

Remove unused libraries and polyfills, split bundles by route so that a page loads only what it needs, load below-the-fold widgets lazily, replace heavy libraries with native browser features and audit dependencies for large packages. Coverage tools in the browser show how much shipped code never runs.

How do you find unused code?

Use the Coverage panel in Chrome DevTools while you use the page, then inspect bundle composition with a bundle analyzer to find the largest dependencies.

How should you handle third-party scripts?

Inventory every tag and ask what business value it provides. Remove those that nobody uses, load the rest after the page is interactive, use the async or defer attributes, and delay chat and survey widgets until the first user gesture. Tag managers make adding scripts easy and removing them rare, so schedule a regular review.

What about consent banners and analytics?

They are legitimate, but they must be efficient. Choose lightweight implementations and avoid loading several overlapping analytics tools that all do the same job.

What about frameworks and rendering strategy?

Client-heavy rendering shifts work onto the visitor's device and increases hydration cost. Server rendering and static generation deliver ready HTML, and partial or progressive hydration reduces the code that must run before the page responds. The trade-offs, including how rendering affects crawling, appear in the analysis of client-side versus server-side rendering, and the same advice that helps Googlebot, delivering content in HTML, also helps INP.

Is a static site naturally better for INP?

Usually, because it ships little script. This site is generated as static HTML with minimal JavaScript, which keeps interactions quick. Interactive features still need care.

How do DOM size, layout and CSS affect responsiveness?

A large, deeply nested DOM makes every style recalculation and layout pass slower, which increases presentation delay after each interaction. Keeping the DOM small and the rendering work contained is a quiet but powerful way to improve INP.

How large is too large?

There is no single limit, but pages with several thousand nodes, or with very deep nesting, tend to suffer. Lighthouse flags excessive DOM size, and DevTools shows the node count. Page builders, mega menus, long comment threads and unpaginated product grids are frequent sources.

How do you reduce DOM size?

Paginate or virtualize long lists, remove hidden duplicate markup such as separate desktop and mobile menus, simplify nested wrappers and load heavy sections on demand.

Which CSS and layout practices help?

Use CSS containment to limit how far a change can ripple, use content-visibility to skip rendering for off-screen sections, prefer transforms and opacity for animation, and avoid reading layout properties right after writing them. Keep selectors simple, and avoid style changes that force the browser to relayout the whole page.

What is layout thrashing?

It happens when code alternates between reading and writing layout-dependent values inside a loop, forcing the browser to recalculate layout repeatedly. Batch reads first, then writes.

How do images and fonts relate?

Large images and late font swaps cause layout work and repaints that compete with interactions. Set image dimensions, compress files and load fonts carefully. The advice in image SEO and Google Images best practices covers formats and sizing that also reduce rendering cost.

Do animations hurt INP?

Heavy, layout-triggering animations can. Use compositor-friendly animations and limit what animates on interaction.

Do hosting, caching and delivery affect INP?

Indirectly, yes. INP is mostly about client-side work, but slow responses delay scripts, hydration and the moment a page becomes interactive. A fast, cached delivery path gives the main thread an earlier, calmer start.

What delivery improvements help?

Serve HTML quickly from a nearby edge, compress and cache static assets, use modern protocols, preload critical resources and avoid render-blocking scripts. Reducing time to first byte helps everything that follows, as the discussion of server response time and crawl frequency explains for crawling and users alike.

Does a content delivery network fix INP?

It helps delivery but does not fix long tasks. If scripts run slowly on the device, a faster network will not change that.

How do you coordinate speed work with LCP and CLS?

Treat the three metrics as one program. Deferring scripts helps INP and LCP, setting image dimensions helps CLS and LCP, and trimming bundles helps all three. Prioritize by which metric fails at the 75th percentile and by which templates carry the most traffic and revenue.

Which template should you fix first?

The one that earns the most organic revenue and shows a poor field value, for example the product page or the booking page.

How do you improve INP on WordPress, Shopify and other platforms?

Hosted and CMS-based sites share one pattern: themes, plugins and apps add scripts faster than anyone removes them. The fix is governance as much as engineering, and the details vary by platform.

What helps on WordPress and WooCommerce?

Choose a lightweight theme, limit page builders that generate deep DOM trees, remove plugins that load scripts on every page, load plugin assets only where they are needed and use caching and a content delivery network for delivery. Audit WooCommerce extensions that add scripts to the cart and checkout, since those are the interactions that matter most for revenue.

Which plugins deserve scrutiny first?

Sliders, popups, live chat, social feeds, heat-map tools and any plugin that loads a large script site-wide. Test each by disabling it and comparing traces.

What helps on Shopify and similar hosted platforms?

Review installed apps, remove those that are unused and replace heavy ones with theme-native features. Defer app scripts where the app allows it, keep theme sections simple and avoid duplicate widgets that do the same job. Hosted platforms limit what you can change on the server, so the front-end budget is where you win.

Can you fix INP without a developer?

Partly. Removing unused apps and plugins, compressing images and trimming page-builder sections are within reach of non-developers, while deeper changes need engineering help.

What helps on custom and JavaScript-framework sites?

Adopt route-based code splitting, partial hydration or islands, server components where your framework supports them, and keep global state updates narrow so that one tap does not re-render the whole tree. Profile components that re-render often and memoize expensive computations that run on interaction.

How does this connect to crawling and rendering?

The same decisions that reduce hydration cost also make content easier for crawlers to read, as the discussion of Googlebot, rendering and the DOM describes.

What is a practical workflow for finding and fixing INP problems?

Work in a loop: measure field data, find the slow interaction, reproduce it in the lab, fix the cause, deploy and watch the field data. Each pass should target the worst interaction on the most valuable template.

What are the steps?

1. Pull field data for your key templates from PageSpeed Insights, Search Console's Core Web Vitals report and any real user monitoring you have.
2. Identify templates and device types with poor or borderline INP at the 75th percentile.
3. Find the interactions responsible, using RUM attribution or by testing the main flows in DevTools.
4. Record a performance trace, locate long tasks and expensive handlers, and classify the delay as input, processing or presentation.
5. Apply the matching fix: yield, defer, trim, simplify the DOM or remove the script.
6. Retest in the lab, deploy and monitor field data for several weeks, since field data updates on a rolling window.

How long until field data improves?

Chrome User Experience Report data is aggregated over a rolling period, so improvements appear gradually over weeks. Do not judge a fix after two days.

How do you stop regressions?

Add performance budgets for script size and long tasks to your build, run synthetic tests on key templates in continuous integration, monitor field INP with alerts and review third-party additions before they ship. A new marketing tag can undo a month of work in an afternoon, so make performance part of the release checklist, alongside the checks in the technical SEO audit checklist.

Who should own INP?

Front-end developers fix it, and SEO and marketing teams control many of the scripts that cause it, so both need to be involved.

What does an INP fix look like in practice?

This is a fictional example that illustrates the method. The outcomes are invented.

What was the situation?

A fictional outdoor-gear store saw mobile INP of about 480 milliseconds at the 75th percentile on its category pages, and add-to-cart taps felt sluggish. Conversion on mobile lagged desktop.

What did the diagnosis find?

Real user monitoring pointed to the filter sidebar and the "add to cart" button. A trace showed a 300 millisecond task on every filter tap that re-rendered 600 product cards, a chat widget initializing a 200 millisecond task just after load and a 3,500-node DOM from duplicated mobile and desktop menus.

What did they change?

They rendered the first 24 products on the server and paginated the rest, updated only changed cards when filters changed, debounced the price slider, delayed the chat widget until the first interaction, removed the duplicate menu markup, split the main bundle by route and moved analytics enrichment after paint. They monitored field data for six weeks, noting that results would vary and that other site changes occurred in the same period.

What did they learn?

Three modest fixes, aimed at the actual worst interactions, did more than any generic speed checklist. Measuring first made the work cheap and focused.

Which INP mistakes should you avoid?

Most failed INP projects start with a score and no diagnosis, or fix lab numbers while real users still struggle.

What do teams get wrong?

Optimizing Total Blocking Time and assuming INP will follow, testing only on a fast laptop, ignoring third-party scripts, shipping a large framework for a mostly static page, fixing only the home page while product pages fail, expecting immediate changes in field data and declaring victory without monitoring.

Which mistake is the most common?

Relying on lab scores. Lighthouse is useful, but it does not observe real interactions, so a perfect lab score can sit beside a failing field INP.

How do you keep the gains?

Monitor field values, enforce budgets, review new scripts and revisit the worst templates quarterly. Responsiveness is a property of your whole front end, and it drifts unless someone owns it.

Where does this sit among other technical priorities?

After crawlability, indexing and content quality, but before cosmetic redesigns. The checklist approach in mobile-first indexing best practices pairs naturally with INP work, because both focus on the mobile experience.

How does AH SEO Agency help with Core Web Vitals and INP?

We collect field and lab data for your key templates, find the interactions that fail, trace them to scripts, handlers and DOM size and give your developers a prioritized fix list. We also set up monitoring and budgets so that gains last, and we report honestly on what changed.

Where do you start?

Request a technical SEO review, add a performance-focused SEO audit or begin with a free SEO audit that includes Core Web Vitals.

Summary: how do you get a good INP?

Measure real user INP, find the worst interaction, identify whether input delay, processing or presentation dominates and fix that part by breaking up long tasks, shipping less JavaScript, trimming handlers and keeping the DOM lean.

• Good INP is 200 milliseconds or less at the 75th percentile, and poor is above 500.
• Only clicks, taps and key presses count.
• Field data is preferred, and lab data is a proxy.
• Third-party scripts, hydration and large DOMs are the usual causes.
• Monitor continuously, because responsiveness regresses easily.