The Mobile vs Desktop Speed Gap: A Study of the Top 500 Sites on the Web

More than 60% of global web traffic now comes from mobile devices, according to Statista. Yet most performance work still happens on a developer's desktop, in a fast browser, on a wired office connection. That setup measures the easy case and ships the hard one.

To answer without guesswork, we used field data rather than lab scores. Lab tools like Lighthouse simulate a single device under controlled conditions. Field data records what real people experienced on their own phones and laptops. Google publishes exactly this kind of data in the Chrome User Experience Report, the same dataset it uses to grade Core Web Vitals and to inform search rankings. We queried it for the 500 most-visited domains on both form factors and compared the results side by side.

The pattern is consistent and, in places, severe. Desktop wins on loading. Desktop wins decisively on interactivity. Mobile claws back a single category, visual stability, and loses everywhere else.

We took the 500 highest-ranked domains from the Tranco list, a research-grade ranking that combines and stabilizes the major top-site lists. For each domain we requested real-user data from the Chrome UX Report API for two form factors, PHONE and DESKTOP. We recorded the 75th-percentile value of each metric, which is the same statistic Google uses to assess Core Web Vitals.

We captured five metrics per site per device: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), Cumulative Layout Shift (CLS), First Contentful Paint (FCP), and Time to First Byte (TTFB). Pure infrastructure and ad-technology domains were filtered out so the sample reflects sites that real people visit.

Across the top 500 sites, the median desktop LCP is 1,699 ms. The median mobile LCP is 2,082 ms. That is a 24% penalty for the typical site, on the metric that most shapes whether a page feels fast or slow.

The headline number is the share of sites affected. On 84% of the top 500 sites, mobile LCP is slower than desktop.

The size of the penalty varies. A quarter of sites carry a mobile LCP penalty of 140 ms or less. But the gap widens fast: half of all sites are at least 408 ms slower on mobile, the top quarter are at least 719 ms slower, and the worst tenth carry a penalty of 1,186 ms or more. For 72 of the 500 sites, the phone takes at least a full second longer than the desktop. For 18 sites, the penalty is two seconds or more.

Research from Think with Google found that as page load time grows from one second to five seconds, the probability of a bounce increases by 90%. Portent's analysis found that a site loading in one second converts at 3.05%, while a five-second site converts at just 0.41%. If your mobile LCP is the metric giving up that ground, our guide has the step-by-step LCP fixes that move it fastest.

Interaction to Next Paint measures the delay between a user action and the screen visibly updating. Google considers anything at or under 200 ms to be good. Above 500 ms a page feels broken.

On desktop, the median site answers an interaction in 76 ms. On mobile, the median climbs to 188 ms, right at the edge of failing. The typical phone user waits roughly two and a half times longer for a site to react. 97% of sites are less responsive on mobile than on desktop. Out of 494 sites with interaction data on both devices, only 13 respond faster on a phone.

Graded against Google's threshold, the collapse is stark. On desktop, 92% of top sites have good INP. On mobile, only 57% do, a 35-point fall driven almost entirely by the move from a laptop processor to a phone processor. INP is the metric most sensitive to JavaScript, because every tap waits for the main thread to finish whatever script it is running before it can respond.

Of the 500 sites, 214 have failing mobile INP above the 200 ms threshold, compared with just 36 that fail on desktop. Twenty sites cross 500 ms on mobile, the point at which an interface feels genuinely unresponsive. See our guide on how to improve INP for the specific main-thread and script-splitting techniques that move this metric.

Core Web Vitals are pass-or-fail as a set. To pass, a site needs good LCP, good INP, and good CLS at the same time, all at the 75th percentile. Among the top 500 sites, 64% pass on desktop. On mobile, only 44% do.

The cross-device view is sharper. Looking only at sites we could evaluate on both devices, 28% pass on desktop but fail on mobile. These are sites whose owners may believe they are passing, because a desktop check told them so, while the experience most of their visitors actually have is a failing one. Almost none pass on mobile while failing on desktop.

This matters beyond the score. Google uses Core Web Vitals as a ranking signal, and the assessment that feeds search is mobile field data. A site that passes in the lab but fails in the field is being judged on the failing number.

Mobile is not beaten everywhere. On visual stability it comes out ahead. Cumulative Layout Shift measures how much the page jumps around as it loads. The median mobile CLS is 0.02, half the median desktop CLS of 0.04. On 60% of sites, the layout is more stable on a phone.

The reason is structural. Mobile layouts are usually a single narrow column, which gives late-loading elements far fewer ways to push content around. Desktop layouts spread content across columns, sidebars, and wider ad slots, each of which can reflow the page. Where mobile constraints force a leaner page, mobile performance improves.

Several household names carry an enormous mobile tax, loading their main content multiple seconds slower on a phone.

Several of these sites take more than six seconds to render their main content on a phone. Figma and Cloudflare's marketing properties both cross eight seconds at the 75th percentile on mobile.

A meaningful minority of sites, 16% of the sample, are actually faster on mobile than on desktop. They tend to share one trait: they ship a deliberately lighter mobile experience instead of shrinking a heavy desktop one to fit.

Netflix is the clearest illustration. Its mobile site renders the main content a full second faster than its desktop site, because the mobile experience is purpose-built to be lean. The 16% that are faster on mobile prove the gap is not a law of physics; it is a budget decision about which experience gets optimized first.

A phone is asked to do the same work as a laptop, parse the same HTML, download and execute the same megabytes of JavaScript, render the same images, on a slower processor, with less memory, and frequently over a higher-latency mobile network. Desktop hardware absorbs page bloat that a mid-range phone cannot.

The gap is widest exactly where you would predict: on loading (LCP) and interactivity (INP), the metrics most sensitive to processing power and JavaScript, and narrowest on visual stability (CLS), where mobile's simpler structure works in its favor.

Much of the extra weight is external code the site owner did not write. Our companion third-party JavaScript growth study puts the median mobile page at 375 KB of third-party JavaScript versus 168 KB of first-party, which lands mostly on the same phone hardware measured here.

The link between mobile speed and business outcomes is well documented. Google has reported that a one-second delay can cost roughly 7% of conversions, and Deloitte's Milliseconds Make Millions study found that improvements as small as 100 ms measurably lift conversion rates. With more than 60% of traffic on mobile and fewer than half of top sites passing Core Web Vitals there, the mobile gap is, for most businesses, the largest unaddressed performance liability on the site.

PageSpeed Matters (June 2026). The Mobile vs Desktop Speed Gap: A Study of the Top 500 Sites on the Web. Analysis of Google Chrome UX Report field data for the top 500 Tranco-ranked domains. The full per-site dataset is available on request for independent verification.

Sample. The top 500 global domains from the Tranco list. Pure content-delivery networks, ad-technology, and infrastructure domains were excluded.

Data source. All performance figures come from the Google Chrome User Experience Report (CrUX) API. CrUX reflects a rolling 28-day window and is the same field dataset Google uses to assess Core Web Vitals. Data was collected in June 2026.

Metrics and thresholds. For each site and each form factor (PHONE and DESKTOP) we recorded the 75th-percentile value of LCP, INP, CLS, FCP, and TTFB. Google's "good" thresholds are LCP at or under 2,500 ms, INP at or under 200 ms, and CLS at or under 0.1. A site passes Core Web Vitals only when all three are good at the 75th percentile.

Comparisons. Aggregate medians are computed across all sites with data for a given metric. Per-site gap statistics are computed only on sites that returned data for that metric on both form factors, so they reflect true like-for-like pairs.

Third-party references. For business-impact context only, we cite published third-party research: Statista (mobile share of web traffic), Think with Google (bounce probability by load time), Portent (conversion rate by load time), Google (the 7%-per-second conversion figure), and Deloitte (the 100 ms conversion finding).