On Phones, Responsiveness Alone Keeps 1 in 20 Websites From Passing Google's Test

Tap a button and wait, even for a third of a second, and something small but real happens: the site stops feeling alive. Responsiveness is the moment a visitor decides whether a page is working for them or fighting them, and on a phone that moment arrives on the weakest hardware most people own. It is the quietest of the speed problems and one of the most punishing.

That lag has consequences a business can measure. A page that hesitates when a shopper taps add to cart, or when a reader tries to open a menu, leaks conversions, trust, and repeat visits. Google folds responsiveness into Core Web Vitals, the real-user signals it has used as a ranking input since 2021, so a sluggish mobile experience costs search visibility on top of the goodwill it burns at the moment of the tap.

To see where responsiveness actually stands, we measured Interaction to Next Paint across nearly 18 million websites using Google's Chrome User Experience Report, the real-user field data collected from Chrome visitors across the web. The split is stark. On desktop, responsiveness is effectively a solved problem. On phones, it is where the modern web still breaks.

The numbers come from the Chrome User Experience Report, Google's record of how real people actually experience the web, assessed at the 75th percentile against Google's official thresholds. A site is good on Interaction to Next Paint when its slowest common taps respond in 200 milliseconds or less, good on loading (LCP) at 2.5 seconds or less, and good on visual stability (CLS) at 0.10 or less. A site passes Core Web Vitals only when all three are good at once. This study covers 17,963,600 origin-device records, split between mobile and desktop, with metric good-rates computed among the origins where each metric is reported.

Interaction to Next Paint, or INP, is the newest Core Web Vital. It replaced First Input Delay in March 2024 and measures something the old metric mostly ignored: how quickly a page actually responds after you tap, click, or type, across every interaction in a visit and not only the first one. It is, more than any other vital, a measure of the device in your hand.

The metric splits cleanly down the middle by device. On desktop, 97.9% of sites pass, and the median site responds in 50 milliseconds, a quarter of the 200 ms threshold Google treats as good. On mobile, 82.5% pass and the median site takes 100 milliseconds. The web feels responsive on a laptop almost everywhere. On a phone, responsiveness is where it still breaks.

The reason is hardware. INP is dominated by main-thread work, meaning JavaScript execution, event handlers, and rendering, and a mid-range Android phone has a fraction of the processing headroom of a desktop. A page that shrugs off a heavy script on a laptop can stall for a third of a second on a phone, which is why a green desktop dashboard tells a site owner almost nothing about how responsive their site feels to real customers.

Split every site by device and the three vitals behave very differently. Loading is worse on mobile, as everyone expects, trailing desktop by 11.8 points. Visual stability is marginally better on mobile, because phone layouts are simpler and single-column. Responsiveness is the outlier: excellent on desktop, materially worse on mobile, and the swing between them, 15.4 points, is the largest of the three.

That gap points the opposite way from stability and runs wider than loading because it traces straight back to the processor. Much of the mobile responsiveness cost comes from the JavaScript framework a site is built on and the third-party scripts stacked on top of it. If you want one number that captures the mobile web running on weaker hardware, INP is it.

It is worth keeping the scale in view, because it is easy to overstate INP. Responsiveness is not the metric that fails the most sites. That is still loading, which is good on just 65.5% of mobile and 77.3% of desktop sites, below INP on both. INP's story is not that it is the biggest problem. It is that it is the most uneven one, nearly absent on desktop and stubborn on the devices least able to fix it.

A site fails Core Web Vitals if it fails any one of the three metrics, so most failures are shared: a slow-loading site usually has other issues too. INP is different on mobile. It frequently sinks a site on its own. Across all mobile sites, 5.0% are good on loading and stability and fall short only on responsiveness, a full 1 in 20 of the entire mobile web. Among sites that have a complete three-metric reading, this same group is about 6.8%, the figure reported in the one-metric-away study. On desktop that figure is just 0.5%, or 1 in 200.

That makes responsiveness the single most fixable mobile-only failure in the study. Fixing INP and nothing else would move 1 in 20 of the entire mobile web from failing to passing. The common culprits are heavy third-party JavaScript that blocks the main thread, and the usual offenders are easy to name: a live chat widget and a tag manager that inject a stack of scripts onto the page. Breaking up long tasks, deferring non-critical scripts, and trimming third-party code move the number directly.

The mobile figure is, if anything, generous. INP is only reported once an origin gathers enough interaction data, and it is measured on 82.1% of desktop origins but only 73.6% of mobile ones, roughly 1 in 4 mobile sites missing a reading. Those missing sites skew small and lightly trafficked, the long tail that tends to run heavy themes on cheap hosting, so the real-world picture across the whole web is probably a touch worse than the headline.

May 2026 CrUX, 75th percentile, strict all-three pass. INP device gap = 15.4 points.

The number that matters is the mobile one, so check Interaction to Next Paint on a real mid-range phone rather than a laptop. A desktop dashboard reads 97.9% pass and a median tap answered in 50 milliseconds, while the same web on mobile passes only 82.5% and takes 100 milliseconds at the median. On phones, 5.0% of all sites are good on loading and stability and fall short on responsiveness alone, a full 1 in 20 that a single fix would move across the line, against 0.5% on desktop.

That fix is almost always third-party JavaScript blocking the main thread, most often a live chat widget or a tag manager loading a stack of scripts. Break up the long tasks and defer what does not need to run at first paint, and the number moves. Desktop has already reached 97.9%, which proves responsiveness is solvable rather than inherent, and the mobile sites that clear it first will feel instant in the hand while their competitors still stutter.