Most mobile sites are still too slow by Google’s own thresholds. In the Web Almanac 2025, 48% of mobile sites had good Core Web Vitals, against 56% of desktop sites. Mobile is improving, but loading speed on phones is where the gap sits. This article covers where the web stands, what slow pages cost according to the studies that can be checked (with the year of each), and what to fix first. For why visitors leave and what load times to aim for, see our guide to page load time benchmarks and user psychology.

Where the mobile web stands in 2026

The most complete public measurement is the Performance chapter of the HTTP Archive’s Web Almanac. It combines Chrome UX Report field data (real Chrome visitors) with HTTP Archive lab tests, and the 2025 edition is based on July 2025 measurements.

Metric and “good” thresholdMobileDesktop
All three Core Web Vitals good48%56%
Largest Contentful Paint (LCP), 2.5 s or less62%74%
Interaction to Next Paint (INP), 200 ms or less77%97%
Cumulative Layout Shift (CLS), 0.1 or less81%72%
Time to First Byte (TTFB), 0.8 s or less44%55%
First Contentful Paint (FCP), 1.8 s or less55%70%
Share of websites with a good score at the 75th percentile of page loads. Source: HTTP Archive, Web Almanac 2025, Performance chapter (published January 15, 2026; July 2025 data).

Read the population carefully. The sites are the ones in the Chrome UX Report, which covers publicly discoverable sites with enough visitors, so low-traffic sites are not represented. A site has good Core Web Vitals when its LCP, INP and CLS all meet the thresholds.

Mobile trails desktop on loading. 62% of mobile sites have a good LCP against 74% on desktop, and mobile has nearly twice the share of poor LCP (13% against 7%). The Almanac calls the gap “consistent with the combined effects of slower networks and less capable devices”.

The server is part of the delay. Only 44% of mobile sites have a good TTFB, and 17% are poor (over 1.8 s). TTFB is not a Core Web Vital, but it comes before First Contentful Paint and LCP, so a slow response delays both. The Almanac notes that it covers connection setup, redirects and server processing.

Interactivity improved, and mobile still lags. Good INP on mobile rose from 74% in 2024 to 77%, which narrowed the gap with desktop from 23 to 20 points. Layout stability is the one metric where mobile does better than desktop.

The trend is up, slowly. The share of mobile sites with good Core Web Vitals was 36% in 2023, 44% in 2024 and 48% in 2025. Desktop was 48%, 55% and 56%, so it barely moved in the last year.

The lab data points the other way. HTTP Archive also loads each page in a controlled test: an emulated Moto G4 on a 4G connection (9 Mbps, 170 ms round trip) with 8x CPU slowdown for mobile, and a Linux VM on a cable connection for desktop. The median Total Blocking Time, a lab proxy for responsiveness, was 1,916 ms on mobile and 92 ms on desktop, and the mobile median rose 58% from 1,209 ms in 2024. The Almanac calls this, next to the improving field INP, “an apparent contradiction”. It suggests that more powerful real-world devices may be masking heavier code, and does not confirm that explanation.

Mid-popularity sites do worst. On mobile, 51% of the 1,000 most popular sites have good Core Web Vitals, against 42% of the next 10,000 and 37% of the next 100,000. The Almanac suggests that mid-sized sites may combine more features and third-party scripts with less sustained attention to performance. It does not test that.

What Core Web Vitals measure, and what Google does with them

Core Web Vitals are three field metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). Google’s targets are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, judged at the 75th percentile of page loads and segmented across mobile and desktop (web.dev).

INP officially replaced First Input Delay (FID) as the responsiveness metric on March 12, 2024. FID measured the delay on a visitor’s first interaction. INP observes every interaction in the visit and reports the worst one, with an allowance for outliers on pages with many interactions.

On search, Google’s page experience documentation says Core Web Vitals are used by its ranking systems and recommends good scores for success in Search. It also says there is “no single signal” and that Search “always seeks to show the most relevant content, even if the page experience is sub-par”, while a great page experience can help when many pages offer helpful content for a query. The documentation gives no figure for the size of the effect, so treat speed as a user experience and conversion issue first.

What slow pages cost: the studies and how old they are

Four numbers appear in most articles about page speed. Each is a single measurement, and they are between 9 and 20 years old.

  • “53% of mobile visits leave after 3 seconds.” Google, March 2016 data, published in Think with Google in February 2017. Anonymized Google Analytics data from 3,700 mobile sites that opted into sharing benchmarks: the share of mobile visits that left a page taking longer than three seconds to load.
  • “100 ms of delay costs Amazon 1% of sales.” Greg Linden’s Stanford talk, 2006. One slide reading “+100 ms -1% sales @ Amazon”, from the engineer who built Amazon’s recommendation engine. The slide gives no method or sample size.
  • “A 2-second slowdown cut revenue per user by 4.3%.” Bing, Velocity conference, 2009. Bing’s own experiment, in which queries per user also fell 1.8%. Google ran a separate test on Search, where a 400 ms delay cut searches per user by 0.59%. The two were not a joint study.
  • “A 100 ms delay hurts conversion by 7%.” Akamai, April 2017 (archived copy). About 10 billion visits to top online retailers over one month, gathered by SOASTA. Akamai’s release says a 100-millisecond delay “can hurt conversion rates by 7 percent”.

They show direction, from search and retail sites at specific moments. Do not apply them to your own site as rates. These newer measurements and tests are better evidence:

  • Portent, April 2022 (observational). A 30-day snapshot of 20 sites (14 B2B lead generation, 6 B2C e-commerce), with load speed from 5.6 million sessions. A site loading in 1 second converted at 3 times the rate of a 5-second site for lead generation, and 2.5 times for e-commerce.
  • Deloitte and 55 for Google, 30 days at the end of 2019 (observational). 37 European and American brand sites and over 30 million user sessions, with no site redesigns during the study. After a 0.1 second improvement in four speed metrics on every page, retail conversion was up 8.4% and travel conversion up 10.1%.
  • Vodafone, A/B test, March 2021. One landing page with traffic split 50/50, about 34,000 visits a day per version. Vodafone states the versions were visually and functionally identical. A 31% better field LCP came with 8% more sales and a 15% better lead-to-visit rate.
  • Rakuten 24, A/B test, page updated August 2022. An optimized and an original landing page, traffic split 50/50 for one month. Revenue per visitor rose 53.37%, conversion rate 33.13% and average order value 15.20%.
  • redBus, company report, page updated May 2023. INP work on its search page, found through real-user data at the 95th percentile. INP on the page improved 72%, and the company reports a 7% overall increase in sales.
  • The Economic Times, company report, page updated December 2021. Site-wide Core Web Vitals work on a site with over 45 million monthly active users. LCP went from 4.5 s to 2.5 s, CLS from 0.25 to 0.09, and the bounce rate fell 43% overall.

The two A/B tests are the strongest evidence in this list. Companies choose which results to publish, so read the lifts as examples of what is possible rather than typical results. To price slowness for your own site, compare conversion between fast and slow sessions in your own field data.

Slow is different from down

A basic uptime check passes as long as the page answers within its timeout, so a page that takes six seconds on a phone is up as far as that check can tell. Speed needs its own measurement. Outages cost money in a different way: Parametrix estimated in July 2024 that the CrowdStrike outage of July 19 cost US Fortune 500 companies (excluding Microsoft) $5.4 billion in direct financial losses. Our guide to the cost of website downtime covers that side.

What to do about it

  1. Start with field data. Check your Core Web Vitals in the Chrome UX Report, which PageSpeed Insights surfaces for sites with enough traffic, and add real-user data of your own if you can. web.dev explains that lab tests limit the variables and typically start with a cold cache, while field data reflects your visitors’ actual devices, networks and locations, and that field data is what you should use to prioritize. Split mobile from desktop, because the gap above is large.
  2. Fix loading before interactivity on mobile. That is where mobile fails most: 62% good LCP and 44% good TTFB, against 77% good INP. For the LCP, web.dev suggests that about 40% of the time should be TTFB and about 40% loading the LCP resource, with under 10% each for resource load delay and element render delay (guidelines, not strict rules). If your TTFB is above the 0.8 second good threshold, look at connection setup, redirects and server processing first.
  3. Make the LCP image easy to find and fetch early. An image is the LCP element on 76% of mobile pages in the Almanac. web.dev says the LCP resource should be discoverable in the HTML source, that you should never lazy-load the LCP image, and that setting high priority on more than one or two images stops helping. About 16% to 17% of pages still lazy-load their LCP image.
  4. Cut main-thread work. Median mobile Total Blocking Time in the lab was 1,916 ms against 92 ms on desktop. For INP, web.dev recommends yielding to the main thread and breaking up long tasks so event handlers stay light. redBus was confident its INP was good until real-user data at the 95th percentile showed otherwise, so measure with real users before you optimize.
  5. Check the pages that earn money, and check after every release. In the Almanac’s page-level data, 45% of mobile home pages and 56% of secondary pages had good Core Web Vitals, so the home page is not a stand-in for the site. Test your checkout, search and landing pages, and again after each release or new third-party tag.

Where Site Qwality fits

Site Qwality has two ways to watch this. Page speed monitoring runs scheduled Lighthouse audits through the Google PageSpeed Insights API against the exact URL you choose, every 6 hours. It stores the four Lighthouse category scores and six measurements (LCP, FCP, CLS, TTFB, Speed Index and Total Blocking Time), and alerts when the performance score falls below a fixed threshold of 0.5. It audits the desktop profile only, and it does not record INP. Real user monitoring collects LCP, INP, CLS, FCP and TTFB from your visitors’ own browsers, so it covers the mobile traffic that the audits do not. Both have a free tier, and you can start free.

Sources