1 The headline — what the field data says
WordPress runs about 43.2% of the public web as of May 2026 and holds roughly 60% of the content-management market — down from a peak of 65% in 2022. (W3Techs · May 2026) That ubiquity is the reason WordPress speed shows up in every aggregate benchmark, and every aggregate benchmark shows the same thing.
The HTTP Archive publishes the CrUX Technology Report, which measures the share of real websites — visited by real Chrome users on real devices — that pass all three of Google's Core Web Vitals on mobile. The November 2025 numbers were summarized by Search Engine Journal in December.
| Platform | Nov 2025 | Jun 2025 | YoY |
|---|---|---|---|
| Duda | 84.87% | 83.63% | Up |
| Wix | 74.86% | 70.76% | Up sharply |
| Squarespace | 70.39% | 67.66% | Up |
| Drupal | 63.27% | 59.07% | Up |
| WordPress | 46.28% | 43.44% | Up, slowest |
| All origins | ~48% | ~49% | Flat |
A WordPress site is roughly 1.8 times less likely to pass Core Web Vitals on mobile than a Squarespace, Wix, or Duda site. That is the gap. It is real and it is not closing quickly. Verified. HTTP Archive CrUX Report · Nov 2025.
Chapter 1, in one line. A WordPress site is about 1.8 times less likely than a Squarespace, Wix, or Duda site to pass Google's mobile field-performance test — and that gap is not closing quickly.
2 Where the gap comes from
Here is where the pitch goes wrong. The conclusion most agencies draw from the headline number is that WordPress itself is the problem. The data does not support that conclusion. Lighthouse mobile performance scores for WordPress have risen from 33 in 2023 to 38 in 2024 to 41 in 2025 — the core is getting faster, not slower. The median WordPress site ships 528 KB of JavaScript on mobile. The median Wix site ships 1,462 KB. The median Squarespace site ships 1,314 KB. The "WordPress is heavy" intuition is wrong at the median. Something else is driving the field gap.
The best decomposition the public data supports — partly arithmetic, partly professional judgment — looks like this:
| Cause | Share of the gap | Confidence |
|---|---|---|
| Hosting and time-to-first-byte | 40–50% | High |
| Page builders (Elementor, Divi, WPBakery) | 20–30% | Directional |
| Plugin sprawl and third-party scripts | 15–20% | Directional |
| WordPress core and Gutenberg | 5–10% | High |
| Theme choice | 5–10% | Medium |
The single largest factor is hosting. Only 32% of WordPress origins have a "good" time-to-first-byte in CrUX. Moving from a $5-a-month shared host to a well-tuned managed host routinely flips a "poor" largest-contentful-paint to "good" with no other change.
The second largest factor is page builders. Elementor alone runs on 18.6% of all WordPress sites and roughly 13% of all websites. A clean Gutenberg migration on the same host typically takes 1.5 to 2.5 seconds off largest-contentful-paint in our measurement.
The uncomfortable conclusion
A well-optimized WordPress site — Gutenberg-only, on a lightweight theme, running on managed hosting — can plausibly match an Astro-on-Cloudflare site in real field measurements. That sentence is uncomfortable for an agency whose business model is selling rebuilds, so it does not get said often. Do not recommend a migration on Core Web Vitals grounds alone if the existing WordPress site is already on managed hosting and uses Gutenberg. Migration only makes sense if there are measured interaction-to-next-paint problems, integration needs WordPress cannot serve, or editor-workflow improvements that are themselves worth the cost of moving.
Chapter 2, in one line. The field gap is hosting first, page builders second, plugin sprawl third — and a well-optimized WordPress site can match a rebuilt one, so the "WordPress is the problem" pitch usually is not the right answer.
3 What "fast" is worth — the revenue evidence
Performance affects revenue. Most of the public studies that quantify it are old, vendor-funded, or both. There are two honest exceptions, and one current dataset on the interaction-side metric.
- +8% sales lift from a 31% LCP improvement. Controlled A/B test. Cleanest causal evidence in the public Core-Web-Vitals literature. Vodafone · web.dev · 2021.
- +13% conversion lift, associated with a 1-second LCP improvement. Multi-month regression on real-user data. Renault · web.dev · 2021.
- +25% mobile retail conversion lift between "poor" and "good" Interaction to Next Paint. n = 997 customer sites. Contentsquare · Nov 2023.
Stats not in this piece
The "1-second delay reduces conversions by 7%" stat traces to Akamai's 2017 retail data and is not a universal law. "Amazon loses 1% revenue per 100ms" is unverifiable internal research from roughly 2006. "53% of mobile users abandon in 3 seconds" is from a 2016 dataset applied to a 2026 baseline it does not describe. Half the speed-and-conversion numbers a salesperson will quote you cannot survive a citation check. Verified.
Chapter 3, in one line. Speed moves revenue at the order of a few to about twenty-five percent in the honest, independently-published studies — and most of the louder figures a salesperson will quote do not survive a citation check.
"Core Web Vitals are therefore best understood as a gate, not a signal of excellence. In an AI-led search landscape, this clarity matters."
Dan Taylor · Search Engine Land · 13 January 2026
Largest publicly disclosed AI-citation × CWV study, n = 107,352 pages.
4 The AI-search question — the newest pitch
The newest pitch is that fast pages improve AI Overview citation rates. The largest publicly disclosed study of the question — Dan Taylor's January 2026 analysis of 107,352 pages — found this is not how the relationship works. Severe Core Web Vitals failure does suppress AI citation; a "poor" page is largely invisible. But going from "good" to "great" does not lift it further. Single-source.
The right disposition: speed is the threshold the page has to clear to be eligible. What earns the citation, once the page is eligible, is the content — structured, sourced, dated, extractable. The lever is editorial. The gate is engineering.
Chapter 4, in one line. Speed is the gate AI-citation eligibility has to clear, not a lift on top of it — going from "good" to "great" does not buy more citations, only being seen at all.
5 The other thing nobody mentions — the 2024–2026 dispute
In September 2024 the founder of WordPress called the largest WordPress host on the internet "a cancer to WordPress" at a public conference. The dispute is still in court. In October 2024, WordPress.org forcibly took over Advanced Custom Fields, a plugin with over two million installs and a commercial owner, and renamed it without the owner's consent. In January 2025, Automattic cut weekly WordPress core contributions from 3,988 hours to 45.
Whatever the legal merits — they will be decided by a judge, not by us — the dispute settled an old debate. Open source has centralized choke points. The plugin registry is one of them. If the platform you are building on depends on a registry one person can revoke access to, "open" is doing less work in the sentence than you thought. A clean database export and a domain registered in the business's own name are the two smallest steps that put the business back in charge of the outcome.
Chapter 5, in one line. The 2024–2026 dispute exposed that open-source ecosystems have single points of control — and a clean database export plus domain ownership are the two smallest steps that put the business back in charge of the outcome.
6 So, should you migrate?
The honest answer is a flowchart, not an opinion.
Existing site on shared hosting, running a page builder, slow: start by moving to managed hosting and removing the builder. That is often a four-figure project, not a five-figure one, and it usually fixes the field-measurable problem.
On managed hosting, using Gutenberg, performing well in CrUX, editor workflow fine: do not migrate. Spend the money on content instead. The compounding asset on a modern small-business site is structured, sourced writing, not the rendering engine.
Well-hosted, fast, but the business has outgrown what a CMS can do — query-driven catalogs, a real customer database, calculators that pull from live data, a content model that does not fit into posts and pages: that is a migration that pays for itself. Not because of speed but because the new system can do things the old one structurally could not. That is the migration we sell.
Chapter 6, in one line. Migrate if the site is on shared hosting with a page builder, or if it has outgrown what a CMS can structurally do — and do not migrate if it is well-hosted on Gutenberg, because that site can match a rebuilt one and the money is better spent on content.