Statistics
Page speed statistics, traced to source
Real, official Google field data and HTTP Archive's own crawl data on the state of the web — by device, by platform, and by page weight — and the gap they leave for local businesses specifically.
This is some of the strongest sourcing on this entire site: Google's own Chrome UX Report is real-user monitoring data collected from actual Chrome users, and HTTP Archive's Web Almanac recomputes that same data split by device and by website platform, at a scale no survey or crawl on this site could match on its own.
None of it measures a segment specific to local businesses directly. That's a real gap, not a minor caveat.
The platform-level data below (WordPress, Wix, Squarespace, Shopify, GoDaddy Website Builder, Duda) is the closest available proxy, because those are the actual platforms a large share of local businesses build on, tracked individually rather than folded into one global average.
How the grading works
The grading is deliberately unforgiving. A statistic from a good organisation still earns a C if the sample size is not published beside the number, because a reader cannot check what they cannot see.
Cite freely
Primary source, dated, with sample and method published. Quote it, with its scope attached.
Cite with scope
Real research with a published sample, but narrower than the way it is usually quoted — self-reported, or one country, or one kind of business.
Cite with caution
Named source and plausible method, but the sample size or methodology is not published where the number is. Attribute it, do not lean on it.
Do not cite
Untraceable, undated, or superseded by later changes to the thing it measured. These are the numbers keeping the roundups alive.
Just over half the web passes Core Web Vitals — but 'the web' and 'mobile' are not the same number
This is genuine, Google-official, real-user-monitoring data — as strong a source type as exists for this question. The catch is one of definition, not credibility: Google's own headline figure pools every device Chrome tracks into a single number, and that number is routinely quoted as though it describes the mobile experience specifically. It doesn't.
55.7%
Grade Aof origins Chrome tracks had good Core Web Vitals across all three metrics, in the July 2026 Chrome UX Report — up from 51.3% eighteen months earlier, in January 2025.
What it does not say This is as strong a source as exists on this site — official, dated, massive-scale, real-user field data rather than a lab test or a survey — and CrUX now discloses the exact origin count behind every monthly figure. The scope limit is real and specific: this headline number pools desktop, phone and tablet traffic into one figure rather than reporting mobile separately, so it is not the number to quote for 'how much of the mobile web passes' — that figure is lower, and is covered in the next section.
62% / 77% / 81%
Grade Amobile pass rate for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift respectively, in 2025 — LCP is consistently the weakest of the three Core Web Vitals on mobile, by a wide margin.
What it does not say LCP — how quickly the largest visible element loads — is the bottleneck metric on mobile by a large margin: a 15-point gap below INP and a 19-point gap below CLS. That is directly relevant to a local business site, where the largest element is very often a hero image above the fold.
What this means for reading any Core Web Vitals statistic, including the ones further down this page
The two figures above measure genuinely different things, and conflating them is the single most common error in how this data gets quoted. "55.7% of the web passes Core Web Vitals" and "62% of mobile pages have good LCP" are both true, both current, and not comparable to each other — one is a blended, all-device figure describing whether an origin passes on every metric at once; the other is mobile-only and describes one metric.
Before repeating any Core Web Vitals percentage, check what population and what metric it actually describes, because the same dataset can produce a flattering blended number and an unflattering mobile-specific one in the same month. That is the same check our research methodology applies to every figure on this site: what was measured, on whom, and when.
The rest of this page is written mobile-first and metric-specific for exactly that reason — it is the harder, more honest number, and it is the one that matters most for a local business whose visitors are disproportionately on a phone.
Mobile has closed most of its gap with desktop since 2021 — except on the one metric where it was never behind
This is the trend the headline pass-rate figures above hide: mobile and desktop have been converging for four straight years, but not evenly, and not on every metric.
48% vs 56%
Grade Aof mobile and desktop pages respectively had good overall Core Web Vitals in 2025 — an 8-point gap, down from 9 points in 2021, after widening to 13 points in 2022.
What it does not say The convergence is real but not a straight line — the gap widened before it narrowed, and 2025's improvement on desktop was described by the Almanac's own authors as 'marginal', up only a single point from 2024. Treat this as a multi-year trend worth watching rather than a settled, permanently closing gap.
97% vs 77%
Grade Aof desktop and mobile pages respectively had good Interaction to Next Paint in 2025 — a 20-point gap, narrowed from 23 points in 2024, the largest single-year narrowing of any Core Web Vitals metric measured.
What it does not say INP is the metric where device hardware matters most directly — it measures how quickly a page responds to a tap or click, and a slower phone processor produces a slower response independent of anything the site itself does. A 20-point gap on this metric specifically is closer to a hardware ceiling than a fixable code problem for a meaningful share of visitors.
81% vs 72%
Grade Aof mobile and desktop pages respectively had good Cumulative Layout Shift in 2025 — the one Core Web Vitals metric where mobile outperforms desktop, not the other way round.
What it does not say The Almanac's own authors note desktop carries a higher share of 'needs improvement' CLS scores (17% versus 10% on mobile) while 'poor' scores are similar across both. A plausible structural reason: desktop pages more often load extra sidebar content, ads and embeds that shift layout after the main content has rendered, while narrower mobile layouts have less room for that kind of late-loading clutter to begin with. That is a reasonable explanation, not a measured one — no study isolating the cause was identified in the sources reviewed on 8 September 2026.
| Year | Mobile good CWV | Desktop good CWV | Gap (points) |
|---|---|---|---|
| 2021 | 32% | 41% | 9 |
| 2022 | 31% | 44% | 13 |
| 2023 | 36% | 48% | 12 |
| 2024 | 44% | 55% | 11 |
| 2025 | 48% | 56% | 8 |
Overall Core Web Vitals pass rate (all three metrics good), by device, tracked each year since the metric's 2021 introduction as a ranking signal. Source: HTTP Archive, Web Almanac 2025 — Performance chapter
What this means for a local business checking its own site
Two figures on this page look contradictory until the mechanism is separated out. Mobile is closing the gap with desktop on overall Core Web Vitals — from 9 points behind in 2021 to 8 points behind in 2025 — and yet on the single metric most tied to raw device processing power, INP, the gap is still 20 points.
The convergence is happening on the metrics a site owner can actually fix — LCP and CLS respond to smaller pages, better image handling and more careful layout — while the metric tied most closely to phone hardware itself is improving more slowly, because a business cannot optimise its way around a visitor's ageing phone.
Practically, that argues for treating LCP and CLS as the two metrics worth active, ongoing attention, and INP as the one where "good enough, and getting slowly better as phones improve" is a more realistic target than "fixed." Our guide to the technical SEO checks that actually matter works through that triage in the same order.
The platform a local business builds on predicts its Core Web Vitals pass rate more reliably than almost anything else measurable at scale
This is the closest available proxy for local-business-specific page speed data, and it is a genuinely useful one: WordPress, Wix, Squarespace, Shopify and GoDaddy Website Builder are exactly the platforms a large share of local businesses actually build on, and HTTP Archive tracks Core Web Vitals pass rates for each, by name, with an exact sample size.
45%
Grade Aof WordPress sites had good Core Web Vitals on mobile in 2025 — the second-lowest pass rate of the ten major CMS platforms HTTP Archive tracks, despite WordPress powering roughly 64% of all CMS-driven mobile sites.
What it does not say The sample size here is enormous by this site's usual standards — nearly 4.9 million tracked WordPress origins, disclosed exactly rather than described as 'thousands'. The finding is genuinely uncomfortable for the single most common platform local businesses build on: market dominance and technical performance are pulling in opposite directions. WordPress's own pass rate has improved substantially since 2023 (28% then, 45% now), so the trend is upward — it remains near the bottom of the table nonetheless.
85% vs 45%
Grade ACore Web Vitals mobile pass rate for Duda, the top-performing platform HTTP Archive tracks, against WordPress's 45% — a 40-point spread between the best- and worst-performing major CMS platforms measured.
What it does not say Duda markets itself specifically to agencies and local-service businesses, which is a plausible explanation for why it out-performs open, general-purpose platforms — its templates and hosting are more tightly controlled. That is a reasonable inference from what the platform is, not a measured cause; HTTP Archive's data shows the correlation between platform and pass rate, not why any individual platform produces it.
| Platform | CWV good | LCP good | Sample (origins) |
|---|---|---|---|
| WordPress | 45% | 53% | 4,840,897 |
| Weebly | 47% | 52% | 51,208 |
| Joomla | 55% | 68% | 177,148 |
| Drupal | 61% | 73% | 150,125 |
| Webflow | 65% | 72% | 96,903 |
| Squarespace | 69% | 76% | 209,442 |
| Wix | 74% | 81% | 374,543 |
| Shopify | 77% | 87% | 562,010 |
| GoDaddy Website Builder | 80% | 92% | 52,387 |
| Duda | 85% | 94% | 81,810 |
Sorted by overall Core Web Vitals pass rate, ascending. Shopify and Webflow have no directly comparable 2024 figure in HTTP Archive's published data, so no year-over-year trend is stated for either. Source: HTTP Archive, Web Almanac 2025 — CMS chapter
Core Web Vitals mobile pass rate by CMS platform, 2025
WordPress, the platform the largest share of local businesses actually use, sits second from the bottom of the ten major platforms HTTP Archive tracks.
Scale 0–100%. HTTP Archive's 2025 crawl, cross-referenced with CrUX; sample sizes range from ~51,000 to ~4.8 million origins per platform. Source: HTTP Archive, Web Almanac 2025 — CMS chapter
What this means for choosing, or auditing, a platform
This table is not a study of local businesses specifically — it is a study of every site on each platform, and plenty of large, complex WordPress installations with heavy plugin stacks are dragging the WordPress average down alongside the simple local-business brochure sites.
No published study segmenting these pass rates by site size or business type was identified in the sources reviewed on 8 September 2026, so treat the table as the strongest available proxy for local-business page speed, not as a direct measurement of it — a distinction worth stating plainly rather than smoothing over.
What travels reliably regardless of that limitation: the platform a business builds on sets a ceiling and a floor before a single word of content is written, through decisions the business itself never makes directly — default image handling, how much JavaScript ships by default, how the hosting is configured. That platform decision is the first thing our website development work interrogates, before anything on the page itself.
A WordPress site is not condemned to a 45% pass rate; the platform's own year-over-year improvement (28% in 2023 to 45% in 2025) shows individual sites can and do beat their platform's average substantially through theme choice, plugin discipline and hosting quality.
But it starts from a harder position than a Duda or Shopify site does, and that starting position is worth knowing before assuming a speed problem is a content or hosting failure specific to one business rather than a pattern shared with millions of sites on the same platform. What the platform sets is a starting position, not an outcome — the local website conversion guide covers what the rest of the page has to do once it has loaded.
Page weight predicts Core Web Vitals pass rate almost as cleanly as platform does — and images are most of the weight
Two separate HTTP Archive datasets converge on the same practical answer: heavier pages fail Core Web Vitals more often, and images are the largest identifiable reason pages are heavy in the first place.
57% down to 30%
Grade Ashare of mobile home pages passing all three Core Web Vitals, from the lightest weight bracket (under 1MB) down to the heaviest (5MB or more) — passing rate falls in every single weight bracket in between, with no exceptions.
What it does not say This is a correlation, stated as one — the Almanac's own text is explicit that 'page weight is not a part of the [Core Web Vitals] calculation' even though the relationship between the two is this consistent. A heavy page and a poor Core Web Vitals score plausibly share a common cause (more images, more scripts, more embeds) rather than weight directly causing failure, but the practical implication is the same either way: a business auditing its own site can use total page weight as a fast, free proxy for whether it is likely to be in trouble on Core Web Vitals, before running a single Lighthouse test.
2.6MB
Grade Amedian mobile home page weight in 2025, against 2.9MB on desktop — both consistent with landing in the weight bracket where mobile Core Web Vitals pass rate has already fallen to roughly 45%.
What it does not say The median page, not an unusual heavy outlier, already sits in the 2–3MB bracket where the data above shows a well-below-average pass rate. This is a fact about the median web page generally, not about local business sites specifically, and no separate local-business page-weight median was identified in the sources reviewed on 8 September 2026.
76% vs 85.3%
Grade Aof mobile and desktop pages respectively have an image, rather than text or anything else, as their Largest Contentful Paint element — meaning image loading time is, for most pages, the direct determinant of the LCP score.
What it does not say This is the mechanism that connects page weight to LCP specifically: on more than three-quarters of mobile pages, the single largest visible element — the one LCP measures — is an image. A hero photo on a local business homepage is not incidentally related to its LCP score; for most sites, it is the LCP score.
90–92%
Grade Aof pages load at least one third-party resource (a tracking script, embedded widget, ad or font), across every website popularity tier measured, with a median of 79 third-party requests per mobile page across the whole dataset.
What it does not say Third-party requests increased year over year despite a fall in the number of unique third-party domains per page, which the Almanac's authors read as individual third parties — analytics tags, tag managers, embedded widgets — sending more requests each rather than sites adding new ones. A business that has not touched its own analytics or tracking setup can still be accumulating third-party weight it never deliberately added.
| Page weight | Mobile pass rate | Desktop pass rate |
|---|---|---|
| Under 1MB | 57% | 70% |
| 1–2MB | 52% | 59% |
| 2–3MB | 45% | 53% |
| 3–4MB | 38% | 48% |
| 4–5MB | 34% | 44% |
| 5MB or more | 30% | 38% |
Home pages only, passing all three Core Web Vitals thresholds. Page weight is not itself part of the Core Web Vitals calculation — the relationship shown here is a strong, consistent correlation, not a mechanical formula. Source: HTTP Archive, Web Almanac 2025 — Page Weight chapter
What this means for where to look first on a slow site
Read together, these figures describe a specific, checkable chain rather than a vague instruction to "make the site faster." Most pages fail LCP because of an image, not because of a script (76–85% of pages have an image as their LCP element).
The median page is already heavy enough to sit in a below-average-pass-rate weight bracket before a single third-party script is even counted, and 90%+ of pages are carrying third-party weight regardless, much of it invisible to whoever last touched the site's actual content.
For a local business checking its own homepage, the highest-value first check is usually the hero image specifically — its file size, its format, and whether it is the first thing the browser is told to fetch — because that single element is disproportionately likely to be both the heaviest thing on the page and the exact element Largest Contentful Paint is measuring.
This site's separate conversion rate statistics page carries the other half of this argument in more depth — what a Core Web Vitals fix is actually worth in conversion terms, using Google's own disclosed Rakuten 24 case study, rather than the pass-rate data this page focuses on.
The same principle that opens this site's local business website statistics — that a meaningful share of visitors are on mobile-only connections with no desktop fallback — is the reason a heavy hero image is a bigger liability for a local business specifically than it would be for a desktop-heavy B2B product. In the FOUND, TRUSTED, CHOSEN framework, speed is where a site quietly loses the people it has already been found by.
What the evidence covers
Chrome UX Report and HTTP Archive's Web Almanac are both genuinely global in scope, unlike most sources cited on this site, which is a point in their favour.
What neither provides is segmentation by business type or size. There's no way to isolate 'local business websites' from either dataset as published, which limits how directly this page answers the question a local business owner actually has — about their own likely performance relative to true peers, rather than to the whole tracked web.
The numbers that did not survive the trace
These appear in current statistics roundups. Each one fails on provenance, and quoting them transfers the failure to you.
100ms / 500ms
Do not citeevery 100 milliseconds of added latency cost Amazon 1% in sales, and a 500-millisecond delay cost Google 20% of its traffic.
Traced to Widely attributed to a 2006 conference remark by Amazon engineer Greg Linden and a 2006 Web 2.0 Conference talk by Google's Marissa Mayer, both referencing internal experiment results.
Both companies' own internal A/B tests may well have found something like this at the time — that part is plausible and not in dispute. What was never published, by either company, in the twenty years since, is the underlying study: no sample size, no methodology, no confidence interval, no raw data, and no link that resolves to a formal paper rather than a conference anecdote repeated in a slide deck. No working citation to an original published document was identified in the sources reviewed on 8 September 2026. It is quoted today exactly as it was in 2010 — as a fact with a precise decimal, from two companies that have since published far more rigorous data (including Google's own Core Web Vitals research cited elsewhere on this page) without ever formally re-confirming this specific two-decade-old figure.
90+
Do not citea Google PageSpeed Insights or Lighthouse performance score of 90 or above is required to rank on page one of Google.
Traced to Circulates constantly in SEO guides and page-speed sales copy, usually unattributed or attributed vaguely to 'Google'.
This conflates two different things Google itself keeps separate. The Lighthouse/PageSpeed Insights score is a lab metric, generated from a single simulated page load under controlled conditions. Core Web Vitals, the thing Google's own Search Central documentation actually ties to ranking, is field data — real users' real experiences, measured against specific per-metric thresholds (good LCP, good INP, good CLS), with no composite score and no published cutoff at 90 or any other number. A site can score below 90 on Lighthouse and still have good, passing Core Web Vitals in the field, and vice versa — the two measurements frequently disagree, which is precisely why Google publishes them as separate systems rather than one score. Treat 'a high Lighthouse score' as a useful lab diagnostic, not as the thing Google's ranking systems are actually reading.
How this page is made and how to cite it
Figures were traced directly to Google's Chrome UX Report release notes and to HTTP Archive's Web Almanac 2025 chapters (Performance, CMS, Page Weight and Third Parties), including the published chart data behind each figure where HTTP Archive makes it available, not just the surrounding prose — the site's chain-of-citation rule in practice.
Last verified: 8 September 2026. Reviewed quarterly; CrUX itself updates monthly and HTTP Archive's Web Almanac republishes annually, so treat any specific percentage as a snapshot rather than a fixed fact.
Preferred citation Parashar, S. (2026). Page speed statistics, traced to source. shrutiparashar.com/statistics/page-speed/
Questions
- What percentage of websites pass Core Web Vitals on mobile?
- 48% in 2025, up from 44% in 2024 and 32% in 2021, according to HTTP Archive's Web Almanac 2025 Performance chapter, which computes Core Web Vitals pass rates from Google's own Chrome UX Report data split explicitly by device. This is different from the 55.7% headline figure Google's Chrome UX Report itself publishes each month, which pools mobile, desktop and tablet traffic into one number rather than reporting mobile separately — a distinction worth checking before quoting either figure.
- What's the difference between the 55.7% Core Web Vitals figure and the 48% mobile figure?
- The 55.7% figure is Google's Chrome UX Report's own monthly headline statistic (July 2026 data), and it combines every device Chrome tracks — desktop, phone and tablet — into a single blended pass rate. The 48% figure is HTTP Archive's Web Almanac, using the same underlying CrUX data but split explicitly by device, reporting mobile on its own. Both are correct, current and well-sourced; they simply answer different questions, and a source quoting one while implying the other is worth treating with caution.
- Is there separate page speed data for local business websites specifically?
- No published breakdown isolating local business site performance from either Google's Chrome UX Report or HTTP Archive's Web Almanac was identified in the sources reviewed on 8 September 2026. The closest available proxy is platform-level data: HTTP Archive tracks Core Web Vitals pass rates by CMS, and the platforms local businesses actually use — WordPress, Wix, Squarespace, Shopify, GoDaddy Website Builder — are measured individually, which at least narrows the gap considerably from a generic global average.
- Which Core Web Vitals metric is hardest to pass on mobile?
- Largest Contentful Paint (LCP), by a wide margin — a 62% mobile pass rate in 2025, against 77% for Interaction to Next Paint and 81% for Cumulative Layout Shift, per HTTP Archive's Web Almanac. LCP measures how long the largest visible element takes to load, and on 76% of mobile pages that element is an image — which is why image weight and format are usually the highest-leverage fix for a failing LCP score.
- Is mobile page speed catching up to desktop, or falling further behind?
- Catching up, on most metrics, though unevenly. The overall Core Web Vitals gap between mobile and desktop was 9 percentage points in 2021, widened to 13 points in 2022, and has narrowed steadily since to 8 points in 2025. Interaction to Next Paint specifically narrowed from a 23-point gap in 2024 to 20 points in 2025 — the fastest single-year improvement of any metric — while Cumulative Layout Shift is the one metric where mobile has consistently outperformed desktop rather than trailed it, for reasons HTTP Archive's own data does not fully explain.
- Does WordPress perform worse than other website platforms on Core Web Vitals?
- Yes, measurably — 45% of WordPress sites had good Core Web Vitals on mobile in 2025, the second-lowest pass rate among the ten major CMS platforms HTTP Archive tracks, despite WordPress powering roughly 64% of all CMS-driven mobile websites. The figure has improved substantially since 2023 (28% then), so the trend is upward, but WordPress still starts from a harder position than most alternative platforms. This describes the platform in aggregate across millions of sites, not any individual WordPress site's ceiling — theme choice, plugin discipline and hosting quality all move an individual site well above or below its platform's average.
- Which website platform has the best Core Web Vitals pass rate?
- Duda, at 85% of mobile sites passing all three Core Web Vitals in 2025, followed by GoDaddy Website Builder (80%) and Shopify (77%), per HTTP Archive's Web Almanac CMS chapter. Both Duda and GoDaddy Website Builder market themselves specifically toward agencies and small local-service businesses, and their more tightly controlled templates and hosting are a plausible explanation for the gap — though HTTP Archive's data shows the correlation between platform and pass rate, not a tested reason for it.
- Why do heavier web pages fail Core Web Vitals more often?
- HTTP Archive's Web Almanac 2025 found mobile home pages under 1MB pass Core Web Vitals 57% of the time, falling in a consistent, unbroken line to 30% for pages of 5MB or more. Page weight is not part of the Core Web Vitals calculation itself, so this is a correlation rather than a mechanical cause — but it is an unusually consistent one, and images are the largest identifiable driver: 76% of mobile pages and 85.3% of desktop pages have an image, rather than text, as their Largest Contentful Paint element, meaning image loading time directly determines the LCP score on most sites.
- Is a Lighthouse or PageSpeed Insights score of 90 or above needed to rank well in Google?
- No — this circulates constantly but conflates two different measurements Google itself keeps separate. Lighthouse and PageSpeed Insights produce a lab score from one simulated page load; Core Web Vitals, the metric Google's own Search Central documentation actually ties to ranking, is real-user field data measured against specific per-metric thresholds (good LCP, INP and CLS), with no composite score and no published numeric cutoff. A site can score below 90 on Lighthouse and still pass Core Web Vitals in the field, and the reverse also happens — the two systems frequently disagree, which is exactly why Google publishes them separately rather than as one number.
- Does page speed actually affect conversion rate, not just Core Web Vitals pass/fail status?
- Yes, and this site's separate local business conversion rate statistics page covers that link in depth, including Google's own disclosed Rakuten 24 case study — a controlled A/B test that found a Core Web Vitals optimisation increased conversion rate by 33% and revenue per visitor by over 53% for one real online store. That page is the place to look for the speed-to-revenue argument specifically; this page's focus is the pass-rate data itself — how much of the web is actually fast, what's slow, and why.
Related reading: how provenance is judged here , local business website statistics , local business conversion rate statistics .
This page is one of 24 in the graded statistics archive, where every figure carries its source, sample and method.
