How to Improve INP (Interaction to Next Paint): A Small Business Guide to Faster Website Clicks (2026)

To improve INP (Interaction to Next Paint), find the clicks, taps and key presses that feel slow on real visitors' phones, then cut the JavaScript work that runs before and during those interactions so the browser can paint visual feedback sooner. Google's web.dev guide to INP defines a good score as 200 milliseconds or less at the 75th percentile of page loads, "needs improvement" as above 200 ms up to 500 ms, and poor as above 500 ms. In practice, most fixes come down to breaking up long JavaScript tasks, delaying or replacing heavy third-party widgets, and keeping the page's DOM and rendering work small.

Last updated: November 2026. This guide is written for small business owners and the people who maintain their websites; every threshold and tool behaviour below is taken from Google's own documentation, linked inline and listed under Sources.

• INP is a Core Web Vital: it replaced First Input Delay (FID) as the responsiveness metric on March 12, 2024.
• The target is 200 ms or less: Google measures INP at the 75th percentile of page loads, separately for mobile and desktop.
• INP has three parts: input delay, processing duration and presentation delay; together they make up the total interaction latency.
• Long tasks are the usual culprit: any main-thread task over 50 ms is a "long task" and can block the browser from responding to a tap.
• Field data comes first: PageSpeed Insights and the Search Console Core Web Vitals report use real Chrome user data from the previous 28 days.
• Good scores help but guarantee nothing: Google says Core Web Vitals are used by its ranking systems, yet good results do not guarantee top rankings.

Interaction to Next Paint measures how quickly a page visibly responds after someone clicks, taps or presses a key. According to web.dev, INP watches every qualifying interaction during a visit and reports roughly the slowest one; on pages with many interactions, one outlier is ignored for every 50 interactions. Scrolling and hovering are not counted. Chrome usage data cited on the same page shows that 90% of a user's time on a page is spent after it loads, which is why a metric that covers the whole visit matters.

The older metric, First Input Delay, only looked at the delay before the very first interaction was handled. The Chrome team announced that INP would replace FID as a Core Web Vital on March 12, 2024, and FID was deprecated in that transition. Today, Google Search Central lists the three Core Web Vitals as Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.

For a small business site, a poor INP usually shows up as small but costly annoyances: a mobile menu that takes a moment to open, a "Book now" button that seems dead on the first tap, a contact form that freezes while it validates, or a product filter that lags on an older Android phone.

Google uses the same three bands across its tools. The thresholds below come from the official INP documentation and are applied at the 75th percentile of real page loads, segmented by mobile and desktop:

• Good: 200 milliseconds or less.
• Needs improvement: more than 200 ms and up to 500 ms.
• Poor: more than 500 milliseconds.

The 75th percentile means three out of four visits must be at or below the value shown. PageSpeed Insights documentation explains that a page or origin passes the Core Web Vitals assessment when the 75th percentiles of INP, LCP and CLS are all Good. If there is not enough INP data, the assessment passes when LCP and CLS are both Good.

Start with real-user (field) data, then move to lab testing to find the cause. These are the free official tools, in the order most small businesses should use them:

• PageSpeed Insights: shows real Chrome user data from the Chrome User Experience Report (CrUX) for the previous 28-day collection period, plus a Lighthouse lab test. If a page has too little traffic, it falls back to data for the whole website (origin).
• Search Console Core Web Vitals report: groups similar URLs and labels them Poor, Need improvement or Good for mobile and desktop. The "Group INP" value is what 75% of page requests achieved over the last 28 days.
• Chrome DevTools Performance panel: records your own local INP as you click around the page, with a table of each interaction and its timing phases.
• The web-vitals JavaScript library: lets a developer measure INP in real visitors' browsers so it can be reported to an analytics or real-user monitoring (RUM) tool; Google notes that RUM data can show which specific interaction was responsible for a poor score.

Details for each tool are in Google's PageSpeed Insights help, the Search Console Core Web Vitals report help page and the Chrome DevTools Performance panel guide. One caution: the Lighthouse score in PageSpeed Insights is a simulated page load without clicks, so it cannot report INP directly. Web.dev notes that Total Blocking Time (TBT) can be a reasonable lab proxy for INP, but it is not a substitute for real INP data.

If PageSpeed Insights shows no INP at all, that is not necessarily an error. Web.dev lists reasons such as visitors who never clicked, tapped or typed, interactions limited to scrolling or hovering, and visits by bots that do not interact with the page.

Google's Optimize INP guide splits every interaction into three subparts. Knowing which one is slow tells you what to fix:

• Input delay: the time from the tap until the page's event code starts running. It grows when the main thread is busy with other work, such as scripts still loading, parsing and compiling, timers or overlapping interactions.
• Processing duration: the time the event handlers (for example, the code behind a button or form) take to finish.
• Presentation delay: the time from the end of that code until the browser paints the next frame. Large, complex pages (a big DOM) make this step slower.

The common thread is the browser's main thread, which can only do one task at a time. Web.dev defines any task longer than 50 milliseconds as a long task; while it runs, taps and clicks have to wait. On small business websites, long tasks often come from page builders that ship a lot of JavaScript, sliders and animation libraries, and stacks of third-party tags. Google's third-party JavaScript guide notes that CPU-intensive script parsing and execution from third parties can delay user interaction, and lists social sharing buttons, video embeds, analytics and A/B testing scripts as typical examples.

Work through these steps in order. Each one is based on Google's published optimization advice; how much it helps depends on what your own data shows.

• Step 1 – Find the slow pages: open the Search Console Core Web Vitals report, filter for INP issues on mobile and fix "Poor" URL groups first, as Google recommends, then "Need improvement".
• Step 2 – Reproduce the slow interaction: open a sample URL in Chrome, use the DevTools Performance panel with CPU throttling, and tap through the main actions (menu, booking button, form, filters) while the page is still loading, when the main thread is usually busiest.
• Step 3 – Audit third-party scripts: list every chat widget, tag, pixel, review badge and embed. Remove anything nobody uses, and load the rest later or only on pages that need them.
• Step 4 – Use facades for heavy embeds: show a lightweight placeholder for YouTube videos and live chat widgets, and load the real embed only when the visitor clicks.
• Step 5 – Break up long tasks: split large functions so the browser can respond between pieces, and keep only the code that updates the screen inside the click handler.
• Step 6 – Shrink rendering work: reduce DOM size where you can, avoid layout thrashing (reading layout values right after changing styles) and consider the CSS content-visibility property for long pages.
• Step 7 – Validate the fix: after deploying, click Start Tracking (validation) on the issue in Search Console and watch the 28-day field data improve.

For Step 4, Lighthouse's third-party facades audit explains the pattern: add a static element that looks like the embed, preconnect on hover, and swap in the real product on click. Google says video embeds, social buttons and chat widgets can all use this approach and points to open-source options such as lite-youtube-embed.

For Step 5, the Optimize INP guide shows a pattern your developer can apply: update the visible part of the interface first, then defer non-urgent work (saving data, analytics, secondary updates) with requestAnimationFrame and setTimeout so it runs after the next frame is painted. The guide also warns that rendering large amounts of HTML with client-side JavaScript can delay the next frame.

Not every improvement needs a developer. Use this comparison to decide where to start:

• Owner-friendly: remove unused plugins, tags, pixels and widgets; turn off auto-playing sliders or animation effects you do not need; replace a heavy embedded video on the homepage with a thumbnail that links to the video.
• Owner-friendly with a tag manager: limit marketing tags to the pages where they are needed, and remove duplicate analytics or tracking codes left behind by old campaigns.
• Developer task: split long JavaScript tasks, defer non-essential code inside click and input handlers, and fix layout thrashing in custom scripts.
• Developer task: build facades for chat and video embeds, reduce DOM size in page templates, and set up web-vitals reporting to collect INP from real visitors.
• Rebuild decision: if a page builder or theme ships so much JavaScript that these fixes are not enough, a leaner rebuild may be the more practical route; compare that cost against the ongoing fixes.

If you are weighing repair against rebuild, our guide on how much a website costs in 2026 explains what affects the budget, and our technical SEO guide covers the other site-health checks worth doing at the same time.

Google's page experience documentation says Core Web Vitals are used by its ranking systems and recommends that site owners achieve good scores. The same page is clear about the limits: there is no single page experience signal, good results in Search Console or third-party tools do not guarantee top rankings, and Google will still show the most relevant content even when page experience is weaker. Chasing a perfect score purely for SEO, Google adds, may not be the best use of your time.

The more practical reason to fix INP is your visitors. A page that responds instantly to a tap on "Call", "Get a quote" or "Add to cart" is simply easier to use. Google has not published any statement that INP is used by AI search features or third-party AI assistants, so treat responsiveness as a user-experience and conversion task rather than an AI visibility tactic.

• web.dev: Interaction to Next Paint (INP), last updated September 2, 2025 – web.dev/articles/inp
• web.dev: Optimize Interaction to Next Paint, last updated September 2, 2025 – web.dev/articles/optimize-inp
• web.dev: Optimize long tasks – web.dev/articles/optimize-long-tasks
• web.dev blog: Interaction to Next Paint becomes a Core Web Vital on March 12 – web.dev/blog/inp-cwv-march-12
• web.dev: Load third-party JavaScript – web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript
• Google Search Central: Understanding Core Web Vitals and Google search results – developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central: Understanding page experience in Google Search results – developers.google.com/search/docs/appearance/page-experience
• Search Console Help: Core Web Vitals report – support.google.com/webmasters/answer/9205520
• PageSpeed Insights: About PageSpeed Insights – developers.google.com/speed/docs/insights/v5/about
• Chrome for Developers: Lazy load third-party resources with facades (Lighthouse) – developer.chrome.com/docs/lighthouse/performance/third-party-facades
• Chrome for Developers: Performance panel overview (DevTools) – developer.chrome.com/docs/devtools/performance/overview