Your website can load quickly and still feel slow.
A customer taps the menu and nothing happens. They choose a service in your booking form, but the next field takes a beat to appear. They click “Add to cart” twice because the first click seems to have been ignored.
Those delays are exactly what Interaction to Next Paint, usually shortened to INP, is meant to measure. INP became one of Google’s three Core Web Vitals after replacing First Input Delay in March 2024, according to the Chrome team’s explanation of the metric. It measures how quickly a page gives visual feedback after clicks, taps, and keyboard interactions throughout a visit.
For a small business, this isn’t a score-chasing exercise. It is about whether a visitor can use your navigation, filters, forms, calculators, and checkout without wondering if the site is broken.
What INP measures
INP observes the latency of eligible interactions and reports one representative value for the page visit. An interaction can include multiple events, such as a key press that triggers keydown, keypress, and keyup. The metric focuses on the longest interaction, with an adjustment for pages that contain many interactions, as described in the official INP reference.
That delay has three parts:
- Input delay: Time from the person’s action until the browser begins running the event handler.
- Processing time: Time spent running the event handlers associated with the action.
- Presentation delay: Time after the handlers finish until the browser paints the next frame.
A page has “good” INP when the 75th percentile of visits is 200 milliseconds or less. Between 200 and 500 milliseconds needs improvement, while more than 500 milliseconds is poor. Google recommends evaluating the 75th percentile separately for mobile and desktop, and those thresholds come directly from the web.dev INP guidance.
This distinction matters because one fast test on your laptop proves very little. The customer on a budget Android phone, using mobile data, may have a very different experience.
Why a fast load time can hide bad INP
Load speed and interaction speed overlap, but they aren’t the same thing.
Largest Contentful Paint measures when the main content becomes visible. INP measures how responsive the page remains when someone uses it. Cumulative Layout Shift measures unexpected visual movement. Together, those three metrics cover loading, responsiveness, and visual stability in the current Core Web Vitals set.
Consider a service business homepage. The hero image may appear in 1.8 seconds, which feels encouraging. Then a visitor opens a location selector. A large script recalculates options, a chat widget initializes, and an analytics tag runs on the main thread. The selector appears 700 milliseconds later. The page loaded quickly, but the interaction was poor.
Common trouble spots on small business sites include:
- Mobile navigation, accordions, popups, and image galleries
- Quote calculators, product filters, booking calendars, and address lookups
- Checkout buttons, variation selectors, and cart drawers
- Cookie banners, chat tools, review widgets, call tracking, and tag-manager scripts
The third-party tool isn’t always the direct cause. Your own code may ask the browser to do too much work at once, or several tools may compete for the main thread at the moment a customer clicks.
Start with real-user data
Don’t begin by opening a developer tool and changing random scripts. First determine whether real visitors have a problem and which page groups are affected.
Check Search Console
Google Search Console’s Core Web Vitals report groups URLs with similar experiences and uses field data from the Chrome UX Report. Google says the report is based on actual usage data and groups performance by status, metric, and URL group in its Core Web Vitals report documentation.
Open the report, choose mobile first, and inspect any “Poor” or “Need improvement” INP groups. Export the affected examples. A grouped report is useful for spotting a shared template problem, such as every product page or every location page using the same slow widget.
Search Console doesn’t always have enough traffic to report an individual URL. That absence is not a passing grade. It means you need another measurement method.
Use PageSpeed Insights correctly
Test one representative URL from each important template: homepage, service page, location page, blog post, product page, cart, booking page, and lead form.
PageSpeed Insights can show field data when enough Chrome users have visited the page or origin. Its lab section runs Lighthouse in a controlled environment. Field and lab numbers answer different questions: field data tells you what eligible Chrome users experienced, while lab testing helps reproduce and diagnose problems. The Chrome team explains those data sources in its Core Web Vitals workflow.
Don’t treat a single lab score as a monthly KPI. Record the URL, device setting, date, INP field status, and any lab diagnostics. Repeat the same process after a meaningful release.
Add real-user monitoring where it pays
The Chrome UX Report, or CrUX, is a public dataset built from opted-in Chrome users. It reports real-world performance at page and origin level when a URL meets eligibility and popularity requirements, according to the official CrUX overview.
Smaller sites and low-traffic pages may not qualify. A lightweight real-user monitoring setup can fill the gap by recording Web Vitals from your own visitors. The web-vitals JavaScript library is maintained by the Chrome team and is designed to measure the metrics as users experience them, as documented in the web-vitals library guide.
Connect measurements to page templates and interaction targets, but avoid collecting typed form values or other personal information. “Quote form, step-two button, 640 ms” is useful. A customer’s message is not needed.
Find the interaction that is actually slow
An origin-level INP number doesn’t tell a developer what to fix. You need the target and the work that happened after the interaction.
Start by using the site like a customer on a midrange mobile device. Open the menu. Change filters. Add a product. Move through the booking flow. Submit a test form. Notice whether visual feedback appears immediately.
Chrome DevTools’ Performance panel can record an interaction and break down its input delay, processing duration, and presentation delay. Google’s diagnostic guide recommends reproducing slow interactions in the lab and inspecting long tasks and event callbacks in the INP optimization workflow.
Write each confirmed issue as a plain business action:
- “Opening the mobile menu takes 560 ms on service pages.”
- “Selecting a product size takes 720 ms before the price changes.”
- “The appointment calendar freezes after choosing a location.”
That language keeps the repair tied to something a customer is trying to do.
Fix the biggest causes in the right order
Break up long JavaScript tasks
JavaScript runs on the browser’s main thread, and a long task can prevent it from responding to a click. The Chrome performance guidance defines a long task as work that occupies the main thread for 50 milliseconds or more and explains that the portion beyond 50 milliseconds contributes to blocking time in its long tasks article.
Developers can split large jobs into smaller chunks and yield back to the browser between them. This lets the browser paint feedback and handle higher-priority input. Google’s INP guidance covers approaches such as scheduler.yield(), setTimeout(), and reducing unnecessary work in its guide to optimizing interaction latency.
The user should see something right away. Change the button state, open the menu shell, or show a progress indicator before starting expensive follow-up work.
Remove work from event handlers
An event handler should do only what the interaction needs now. If clicking a filter also recalculates hidden items, updates five analytics systems, stores preferences, and rebuilds unrelated page sections, the customer waits for all of it.
Reduce the amount of DOM work, avoid repeated layout calculations, and defer nonessential tasks until after the next paint. The browser can be forced into costly layout work when JavaScript reads geometric values after changing styles, a pattern explained in web.dev’s guidance on avoiding layout thrashing.
This often produces a better result than replacing the site’s framework or buying faster hosting. Server speed matters before the page arrives. INP problems frequently happen in the visitor’s browser after the page has loaded.
Audit third-party scripts by business value
List every script loaded through the site and tag manager. Record its owner, purpose, pages, approximate performance cost, and whether anyone still uses the data or feature.
Remove abandoned experiments and duplicate trackers. Load chat, heatmaps, maps, and review widgets only where they are needed. Delay nonessential code until after the page becomes interactive, but test carefully so consent and attribution still work as intended.
Google’s performance guidance warns that third-party scripts can block the main thread and recommends loading them efficiently, including async or defer where appropriate, in its third-party JavaScript guide.
Ask a blunt question: does this tool earn enough leads, sales, or insight to justify making every visitor’s browser process it?
Keep the page structure manageable
A very large or deeply nested DOM gives the browser more work when styles and layouts change. Lighthouse flags excessive DOM size when a page contains too many elements, excessive depth, or too many children under one parent, as detailed in Chrome’s DOM size diagnostic.
Product grids, page-builder sections, hidden mega menus, and duplicated mobile markup are frequent sources. Render only the items the customer needs, paginate or virtualize long lists, and remove hidden components that never become visible.
A 30-day INP repair plan
During week one, establish a baseline. Export Search Console groups, test every revenue-producing template, and record the interactions that feel delayed. Rank them by business value and number of affected URLs.
During week two, remove dead third-party tags and fix the worst shared-template interaction. A slow navigation component that appears on 400 pages deserves attention before a decorative animation on one article.
During week three, optimize forms, filters, booking, and checkout. Add immediate visual feedback, shorten event handlers, and split long tasks. Test on mobile hardware, not only desktop emulation.
During week four, deploy, verify that the actual interaction improved, and annotate the release. Field data takes time to reflect new visits because Core Web Vitals are evaluated over a rolling period. Search Console describes its report as using a 28-day collection period, so don’t expect the status to flip the morning after deployment.
Google says good Core Web Vitals can contribute to success in Search, but they do not guarantee top rankings, and page experience involves more than these metrics. That qualification appears in Google’s Search Central Core Web Vitals documentation. Fix INP because customers need a responsive site. Treat any SEO benefit as part of the return, not the only reason.
If your forms, menus, or checkout feel sticky and you need help finding the code responsible, talk with Your Web Team. We’ll identify the slow interactions, prioritize the fixes, and measure the result on the pages that produce revenue.
