Blog August 25, 2026 8 min read

A finger pressing a button as slate ripples radiate outward while the button itself stays unlit and unresponsive.

The Unresponsive Button Problem: When 'Loaded' Isn't 'Usable'

Here is a scenario that is not unusual. A Tampa Bay law firm updated its website last year. Load time improved. The partners checked the speed report, saw green indicators, and considered the performance work done.

But visitors to the site’s contact page tap the “Get a Free Consultation” button and nothing happens for 1.8 seconds. The page loaded in 2.5 seconds. The speed test passed. The button, to the visitor’s perception, is broken. A portion of those visitors tap again, assume the site has frozen, and leave. The ones who wait and eventually see the form open are the exception. The ones who leave are not tracked in any standard analytics report as “left because button didn’t respond.” They are counted as a bounce, and a bounce from an attorney’s contact page looks identical to a bounce from someone who was never the right visitor in the first place.

The metric that would have caught this failure is called INP. Most businesses have never heard of it, and many of the agencies that serve them haven’t checked it either.

What INP Measures and Why It Is Different From Load Speed

INP stands for Interaction to Next Paint. In plain language: it measures how long every tap, click, and keypress on your site takes to produce a visible response. Not just the first click when the page loads, every click throughout the entire session.

Google made INP an official Core Web Vital in March 2024, replacing the older FID (First Input Delay) metric. FID measured only the first interaction on a page. INP measures all of them. A site that responds quickly to the first click but slogs through subsequent taps, a multi-step form, a navigation menu, a filter on a product page, will fail INP even if it passed FID.

Google’s threshold for “good” INP is 200 milliseconds at the 75th percentile of real user field data. That means 75% of your actual visitors, on their actual devices and connections, must experience responses within 200 milliseconds for your site to pass. “Needs improvement” runs from 201 to 500 milliseconds. Above 500 milliseconds is “poor.”

At 800 milliseconds, users begin to notice the delay consciously. At 1,800 milliseconds, the scenario from the law firm above, the interaction reads as a malfunction.

How Many Sites Actually Fail

According to the HTTP Archive Web Almanac 2024, which analyzed CrUX field data from approximately 16.9 million websites, 74% of mobile origins pass INP. That means more than one in four mobile sites fail user responsiveness, even though INP replaced a metric that 95% of sites were passing.

The gap between mobile (74% passing) and desktop (97% passing) is stark. A 2026 analysis published by Blck Alpaca, drawing on CrUX and RUMvisions data, found that median Total Blocking Time, a proxy for the JavaScript execution overhead that causes INP delays, is approximately 1,208 milliseconds on mobile versus 67 milliseconds on desktop. That is roughly 18 times worse on mobile. The same JavaScript that runs fine on a desktop browser is creating interaction delays on mobile devices that register as broken behavior.

This means a business whose team tests the website on their office laptops is looking at a fundamentally different experience than a mobile visitor on a 4G connection during their commute.

Why Load Speed and Interaction Speed Are Different Problems

A site can pass Google’s LCP threshold (Largest Contentful Paint, the time until your main visible content loads) and still fail INP by a significant margin. These are independent failure modes with different causes and different fixes.

LCP is primarily a delivery problem: the content needs to arrive faster. The solutions involve server infrastructure, image optimization, and reducing what blocks the browser from rendering the page.

INP is primarily a JavaScript execution problem: after the page loads, there is too much code running on the main thread, competing with the user’s interactions for processing time. When a visitor taps a button and that tap has to wait in line behind a JavaScript task that is already running, a lazy-loading image, an analytics ping, an ad loading in the background, the response delay is the result.

The practical consequence: fixing load speed does not fix interaction speed. A business that improved its LCP from five seconds to two seconds, saw better speed-test results, and concluded the performance work was done may still have an INP problem that is causing visitors to experience the site as broken. The problems are separate and require separate diagnosis.

What the Evidence Shows About Business Impact

A four-site e-commerce analysis of the relationship between INP and conversion rate, cited by Blck Alpaca in 2026, found a consistently negative correlation between INP and conversion rate, with the effect visible even at INP values as low as 100 milliseconds. This is indicative analysis from a secondary source, the original study is not independently verifiable from the citation, but the direction is consistent with the broader body of evidence on interaction delay and user behavior.

The redBus case study offers a more substantial data point. redBus, a travel booking platform, reduced their INP by 68% to 72% (figures vary slightly across citations of the original case study) and tracked a 7% increase in sales. This is a single-site case study in the travel booking vertical, published by Google web.dev. It is not a controlled experiment and should not be read as proof that any INP improvement delivers a 7% sales gain. But it is a documented instance of a large-scale operation connecting interaction responsiveness directly to a revenue outcome, not just to a performance metric.

The Economic Times case is more complex. Times Internet published data showing a 50% reduction in bounce rate and a 43% increase in pageviews on topic pages after improving INP from over 1,000 milliseconds to 257 milliseconds. Those figures are real and have been confirmed by multiple independent sources. They must be read with a significant caveat: the same engineering project migrated the site to Next.js simultaneously. The INP improvement and the platform migration happened together, and there is no way to isolate how much of the engagement improvement came from better interaction responsiveness versus other changes introduced by the migration. Use the Times Internet figure as directional context, not as a standalone proof of INP’s effect.

A Worked Example at Small Business Scale

A medical practice in Tampa Bay has 1,200 monthly visitors to its website. The site loads in about three seconds, below Google’s LCP threshold, passing. The practice’s form-completion rate is 3%, which means 36 patient inquiry form completions per month.

The site’s INP, when measured against real user data, is 800 milliseconds at the 75th percentile. That falls squarely in Google’s “needs improvement” range. The multi-step form on the appointment page requires several clicks, date selection, service type, insurance, and each of those clicks is delayed by nearly a second of visible lag.

The visitors who complete the form are determined. The visitors who tap the first field, see no response, and assume something is broken are not counted as “INP failures” in any analytics report. They are bounces.

Improving INP to under 200 milliseconds does not guarantee a specific conversion lift, conversion rate depends on content, pricing, trust signals, and the offer itself. But a site with 800-millisecond interaction delays is not giving its content a fair chance to convert. The form is working against itself.

Why a Passing Speed Test Does Not Mean You Are Done

The most common objection from business owners who have done recent performance work: “I already fixed my load speed. I got a good score on the speed test. Why are you telling me I have a problem?”

Because load speed and interaction responsiveness are separate problems. Because Lighthouse, the most widely referenced speed testing tool, cannot measure INP at all. INP requires real user interaction; a lab simulation cannot generate it. A Lighthouse score showing no INP issues is simply a report that Lighthouse cannot assess INP, not that your INP is good.

Because the metric changed in March 2024. Sites that earned passing grades on FID before that date did not automatically pass INP. INP is harder to pass and measures behavior throughout the entire session, not just the first click.

Because the gap between desktop performance and mobile performance is large enough that testing on a laptop in your office does not tell you what your visitors on mobile are experiencing.

If you fixed load speed and still see bounce rates higher than expected, still see visitors leaving your contact pages without submitting forms, and still cannot explain why, INP is the most likely unmeasured cause. It is diagnosable with free Google tools in under 20 minutes if you know what to look for.

What the Assessment Covers

Gabriel Lopez-Seco runs free assessments for Tampa Bay businesses and national clients that include INP as a specific diagnostic item, not a Lighthouse score, but field data showing actual interaction delays experienced by real visitors. If your site is in the “needs improvement” or “poor” range for INP, the assessment produces a specific list of what is causing it and what the fix involves.

No account manager, no handoffs. One senior conversation. Book yours at iServU.