52.8% of mobile websites passed all three Core Web Vitals in the HTTP Archive's September 2026 dataset, which reads Chrome's real-user data for 8.57 million origins. In January 2020 the figure was 22.8%. The web has more than doubled its pass rate in six years, and almost half of it still fails on the phone in a visitor's hand.
This page sets out where speed stands in 2026, which measure fails most, how page weight has moved, and what the published tests say speed does to bounce, conversion and revenue. Field data comes from the HTTP Archive's technology report and the 2025 Web Almanac; the business figures come from Google's case studies, Deloitte and Portent, with the method and age of each one stated.
How many websites are fast enough in 2026
Google's Core Web Vitals are three field measurements taken from real Chrome users: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. A site passes when 75% of visits are good on all three, judged separately on mobile and desktop. The good thresholds are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less, as web.dev sets them out. INP replaced First Input Delay as a stable Core Web Vital in 2024.
| Month | Mobile | Desktop |
|---|---|---|
| January 2020 | 22.8% | 37.2% |
| January 2021 | 22.1% | 30.2% |
| January 2022 | 35.1% | 42.2% |
| January 2023 | 40.5% | 45.9% |
| January 2024 | 46.8% | 53.5% |
| January 2025 | 47.5% | 56.3% |
| January 2026 | 53.0% | 59.0% |
| April 2026, the peak | 54.2% | 59.5% |
| September 2026 | 52.8% | 60.8% |
Source: HTTP Archive Core Web Vitals Technology Report, all origins, all geographies, read through its public API on 2026-10-20
Two things stand out. The biggest jump came between January 2021 and January 2022, when the share of origins with good mobile CLS went from 54.2% to 70.5%. And the mobile figure has drifted down since April 2026 while desktop kept rising. The cause is responsiveness, not loading: mobile LCP held at about 66%, while mobile INP slid by nearly three points.
The Web Almanac's 2025 performance chapter, built on July 2025 data and counted slightly differently, puts the mobile pass rate at 48% and desktop at 56%. It also finds home pages pass less often than inner pages, 45% against 56% on mobile, which matters because the home page usually carries the hero video, the chat widget and most of the tags.
Which measure fails most
| Metric | Good threshold | Mobile | Desktop |
|---|---|---|---|
| Time to First Byte | 0.8 s or less | 45.9% | 58.2% |
| First Contentful Paint | 1.8 s or less | 57.6% | 75.4% |
| Largest Contentful Paint | 2.5 s or less | 65.6% | 79.0% |
| Interaction to Next Paint | 200 ms or less | 79.4% | 97.6% |
| Cumulative Layout Shift | 0.1 or less | 83.4% | 74.6% |
| All three Core Web Vitals | n/a | 52.8% | 60.8% |
Sources: HTTP Archive Core Web Vitals Technology Report, September 2026; thresholds from web.dev and the Web Almanac 2025
Time to first byte is not a Core Web Vital, but it sits underneath every loading metric. When fewer than half of mobile origins get the first byte back within 0.8 seconds, a good LCP has to be won in the remaining 1.7 seconds. Desktop is the one place layout shift is worse than on mobile, 74.6% good against 83.4%.
The Web Almanac explains where LCP time goes. The LCP element is an image on 76% of mobile pages, and 16% to 17% of pages lazy-load that image, which delays the most important picture on the page on purpose. Only about 17% of mobile pages mark it with fetchpriority="high". 62% of mobile pages have at least one image without set dimensions, the commonest cause of layout shift. And the median mobile page blocks the main thread for 1,916 milliseconds in lab tests, up 58% in a year, which is the INP problem in one number.
Popular sites are slower than the long tail
| Chrome rank group | Mobile origins | All three, mobile | All three, desktop | Good INP, mobile |
|---|---|---|---|---|
| Top 1,000 | 752 | 54.4% | 64.4% | 64.4% |
| Top 10,000 | 7,318 | 46.4% | 61.1% | 59.4% |
| Top 100,000 | 72,655 | 42.7% | 60.3% | 58.5% |
| Top 1 million | 747,521 | 46.6% | 61.9% | 65.7% |
| Top 10 million | 6,407,197 | 53.4% | 61.0% | 79.1% |
| All origins | 8,569,446 | 52.8% | 60.8% | 79.4% |
Source: HTTP Archive Core Web Vitals Technology Report, rank filters, September 2026. Groups are cumulative: the top 10,000 includes the top 1,000.
Busier sites load their main content well. 81.1% of the top 1,000 have a good mobile LCP, against 65.6% of all origins. They lose on responsiveness: fewer than six in ten of the top 100,000 have a good mobile INP. Those sites run more JavaScript, more tag managers and more personalisation, and every one of them competes for the main thread when a visitor taps. A B2B marketing site that adds a chat widget, an intent-data script and a consent manager is copying the pattern of the top 100,000, not the top 1,000.
Pages keep getting heavier, mostly with JavaScript
| Resource | January 2020 | January 2023 | September 2026 | Change since 2020 |
|---|---|---|---|---|
| Total, mobile | 1,877 | 1,883 | 2,504 | Up 33% |
| JavaScript, mobile | 407 | 500 | 714 | Up 75% |
| Images, mobile | 939 | 712 | 753 | Down 20% |
| Total, desktop | 2,073 | 2,152 | 2,911 | Up 40% |
| JavaScript, desktop | 436 | 562 | 835 | Up 92% |
Source: HTTP Archive technology report page-weight data, all origins, read 2026-10-20; KB here is 1,024 bytes
Images got lighter as WebP, responsive images and better compression spread. JavaScript almost doubled on desktop and grew three quarters on mobile, and that is the part that costs a phone the most, because it has to be parsed and run as well as downloaded. The Web Almanac's 2025 page weight chapter adds the long tail: the home page at the 90th percentile weighed 11,406 KB, and the median page carried 315 KB of video, up 28% in a year.
What load time does to bounce
The bounce figures in circulation are older than most people quoting them realise.
| Source | Year | Method | Finding |
|---|---|---|---|
| Google and SOASTA | 2017 | Neural-network model | 53% of mobile visitors leave a page taking over 3 s; bounce probability up 113% from 1 s to 7 s |
| BBC, as reported by web.dev | Undated | Own analytics | 10% more users lost per extra second |
| The Economic Times | 2020 to 2021 | Before and after, field data | LCP 4.5 s to 2.5 s, CLS 0.25 to 0.09; bounce rate down 43% |
| Rakuten 24 | 2022 | A/B test, one month | Exit rate down 35.12% |
Sources: AMP Project blog reporting Google and SOASTA; web.dev Why speed matters; web.dev case studies
The 53% figure is from a model, not an observed test, and dates from a web where the average mobile landing page took 22 seconds to load. It is still directionally right, and the later studies agree on direction, but none of them gives a modern, cross-industry bounce curve. If someone quotes "53% leave after three seconds" as 2026 data, it is not.
What speed does to conversion and revenue
Our B2B SaaS Landing Page Statistics 2026 post covered the Deloitte and Portent studies from the lead-generation angle. Here they sit next to the controlled tests, sorted by how much each method proves.
| Study | Design | Speed change | Result |
|---|---|---|---|
| Vodafone, 2021 | 50/50 A/B test, paid-media landing page | LCP 31% better, 8.3 s to 5.7 s | Sales up 8%, lead-to-visit up 15% |
| Rakuten 24, 2022 | 50/50 A/B test, one page, one month | Loads 0.4 s sooner on mobile | Revenue per visitor up 53.37%, conversion up 33.13% |
| Deloitte and 55 for Google, 2020 | 37 brands, 30 million sessions, 30 days | 0.1 s gain on four metrics | Lead-gen form progression up 21.6%, retail spend up 9.2% |
| Portent, 2022 | 100 million page views, 20 sites, 14 B2B | 1 s against 5 s | B2B conversion about 3 times higher; ecommerce 2.5 times |
| redBus, 2023 | Before and after | Search page INP from 870 ms or more to under 370 ms | Sales up 7% |
| Swappie, 2021 | Before and after | LCP 55% lower, CLS 91% lower | Mobile revenue up 42% |
Sources: web.dev case studies; web.dev Milliseconds make millions; Portent
Only the first two isolate speed. Vodafone split about 34,000 paid visits a day per version between two copies of one page that differed only in performance work, and also saw cart-to-visit rise 11%. Rakuten 24 did the same with no functional or visual change, and order value rose 15.20%. Deloitte's study is correlational: it compares sites whose speed moved with their own funnel metrics over 30 days. Portent's B2B rates use each site's own conversion definition, so the multiples matter more than the 40% headline it reports at one second. The before-and-after studies cannot separate speed from whatever else changed in those months.
These case studies are also published by Google, which defines Core Web Vitals and benefits from a faster web. That is not a reason to dismiss them; it is a reason to expect that no one published the tests where a faster page changed nothing.
What Google says speed does to rankings
Google's documentation, last updated in September 2026, says plainly that Core Web Vitals are used by its ranking systems, that there is no single page experience signal, and that other page experience aspects do not directly help a site rank. The same page states that Search "always seeks to show the most relevant content, even if the page experience is sub-par", and that a good experience can help when many pages are equally helpful.
Read that as a tie-breaker, not a lever. A slow page with the best answer still ranks. A fast page with an average answer does not jump the queue. Speed earns its budget on conversion, and the ranking effect is a bonus.
Figures we left out
The most repeated speed statistics are an Amazon figure on latency and sales, a Walmart figure on load time and conversion, and Akamai's 2017 retail performance report. We could not open a primary source for the first two, and Akamai's report page no longer returns its text, so none of them is used here. If you see them in a 2026 deck, ask for the link.
What this means for a site build or rebuild
Set the budget in field terms before design starts: LCP of 2.5 seconds or less and INP of 200 milliseconds or less at the 75th percentile on mobile, for the home page and the two or three pages that carry conversions. Then design to it. Do not lazy-load the hero image, give every image its dimensions, keep third-party scripts on a list with an owner, and test the page on a mid-range phone, not a developer laptop.
Platform matters less than discipline, but it is not neutral. In the same September 2026 HTTP Archive data, 71.3% of Webflow origins passed Core Web Vitals on mobile against 48.3% of WordPress origins. We build marketing sites in Webflow, so read that with our bias in mind; our Webflow vs Framer in 2026 post sets the platforms side by side. Either platform can be made slow by a hero video and four tracking scripts. Our Webflow development service page explains how we scope a build with a speed budget in the brief.
