For years, talking about a CMS was almost the same as talking about “making publishing easier.” In 2025, that idea is outdated. CMS platforms have become the default infrastructure for a large portion of the web—and that means they quietly shape a lot of technical outcomes: hosting models and defaults, real page weight, visual stability, and whether a site can perform well on mobile without heroic workarounds.
The CMS chapter of the Web Almanac 2025 (HTTP Archive) grounds the discussion with measurement-based data. It doesn’t try to crown a single “winning CMS.” Instead, it describes a mature, increasingly fragmented market where the final user experience is decided mostly by implementation: themes, plugins, builders, third parties, caching, CDNs, and operational discipline.
CMS Isn’t “Optional” Anymore: It’s the Web’s Standard
The first number sets the tone: in 2025, “CMS-driven” sites exceed 54% of the observed web. And that trend has been building for years.
Table 1 — CMS adoption (trend 2021→2025)
| Platform | 2021 | 2025 |
|---|---|---|
| Desktop | 42% | 55% |
| Mobile | 43% | 54% |
In other words: the “no CMS” web isn’t gaining share—it’s shrinking proportionally. For sysadmins, this also means the average performance of the internet is increasingly tied to operations decisions: cache configuration, media policies, JavaScript control, and how content is governed when editors have lots of knobs to turn.
The report also shows meaningful geographic differences: Italy leads (mobile 51%), while the U.S. and U.K. hover around 49%. On the other end, Indonesia (25%) and Brazil (32%) sit at the bottom of the group.
WordPress Still Leads… but Growth No Longer “All Goes There”
On mobile market share, WordPress remains the big reference point. But the interesting part is no longer just the scale—it’s the shift in momentum: WordPress growth slows, while the rest of the market chips away in small increments that add up to a more distributed ecosystem.
Table 2 — CMS share (mobile, 2025)
| CMS | Share |
|---|---|
| WordPress | 64.3% |
| Shopify | 7.3% |
| Wix | 5.2% |
| Squarespace | < 3% |
| Joomla | < 3% |
| Webflow | < 2% |
| Drupal | < 2% |
A key point in the chapter: there isn’t one “WordPress killer.” Shopify sits around 7.3–7.8%, Wix around 5%, and Squarespace around 3%. That’s fragmentation and choice—but not a single wave displacing the leader.
When Traffic Goes Up, the CMS List Changes
One of the most useful takeaways for systems and dev teams comes from the “top sites” view. In the top 10,000, WordPress accounts for ~58% of CMS usage, and Drupal rises to ~6–7%, far above its global share. At that traffic tier, platforms like Wix or Shopify are almost absent: high-traffic sites often bring engineering needs, deep customization, and complex workflows that push teams toward different stacks.
WordPress and Variance: The “Builder” Effect
If WordPress is the biggest CMS, its most defining technical trait isn’t its share—it’s its variance. In the real world, two WordPress sites can feel like entirely different technologies depending on hosting, theme, plugins, caching, third parties, and especially the page builder layer.
The chapter shows a transition: traditional builders are losing share while “block-native” approaches grow—though legacy still dominates many installs.
Table 3 — WordPress page builders (2024→2025)
| Builder | 2024 | 2025 |
|---|---|---|
| Elementor | ~56% | ~43% |
| Block Editor | n/d | ~18% |
| WPBakery | ~21% | ~13% |
| Divi | ~14% | ~10% |
| Beaver Builder | n/d | ~2% |
For sysadmins, this maps to a familiar reality: the same “platform label” with different editorial tooling can explode DOM complexity, increase JavaScript, and worsen INP—without anyone “changing the server.”
Core Web Vitals: Controlled Environments Improve Faster
On mobile, the report shows that more managed platforms with tighter defaults tend to improve faster in the share of sites achieving “good” CWV.
Table 4 — YoY improvement in “good” CWV (mobile, 2024→2025)
| Platform | Δ YoY (approx.) |
|---|---|
| Wix | +14% |
| Duda | +11% |
| Squarespace | +8% |
| Joomla | +7% |
| WordPress | +4% |
| Drupal | +4% |
| Weebly | −1% |
On specific metrics, the same pattern shows up: progress exists, but it doesn’t propagate evenly in ecosystems where every site can be radically different.
- LCP (mobile): in 2025, 54% of sites hit “good” LCP.
- CLS (mobile): Wix shows strong improvement; others move less; Weebly declines.
- INP (mobile): improvements are modest overall, a sign that responsiveness remains a shared problem when JavaScript and third-party scripts are heavy.
The operational takeaway is straightforward: when a platform controls more, improvements reach more sites. When a CMS is highly extensible, gains depend on local decisions.
Lighthouse: High SEO Scores, but Mobile Performance Splits the Field
Lab data (Lighthouse) isn’t the same as real-user data, but it’s helpful for comparing “typical” implementations under consistent conditions. For performance, the mobile gap is especially striking.
Table 5 — Lighthouse Performance (median, 2025)
| CMS | Desktop | Mobile |
|---|---|---|
| Wix | 87 | 64 |
| Duda | 81 | 57 |
| Webflow | 73 | 58 |
| Shopify | n/d | 52 |
| WordPress | 63 | 41 |
| Joomla | n/d | 40 |
For SEO, nearly everyone scores high (roughly 92–100), suggesting the basics are widely built in. Where bigger differences appear is Best Practices, which often correlates with implementation quality, accumulated debt, and resource configuration.
Page Weight: The Bottleneck Isn’t HTML—It’s Images and JavaScript
The chapter highlights an uncomfortable baseline: average page weight in 2025 is about 2.67 MB on desktop and 2.28 MB on mobile—above what many teams would consider healthy for a fast, accessible experience.
More importantly, it reinforces the breakdown: HTML is rarely the problem. The real cost sits in images and JavaScript—formats, sizing, lazy loading, third-party inventory, long tasks, and interaction overhead.
In practice, that leads to a lesson many teams learn the hard way: optimizing without a page-weight budget and observability (RUM + CWV + cache/CDN metrics) is more intuition than engineering.
New Browser APIs: Helpful, but Not Magic
The report points to emerging APIs that can improve perceived speed and navigation (Speculation Rules, View Transitions, and metrics like LoAF to better understand INP). The key nuance: these can smooth variance and improve “how a site feels”… but they don’t compensate for heavy pages or an uncontrolled third-party chain.
CMS in the Age of LLM-Based Search: Structure, Semantics, and Efficiency Matter More
Another increasingly relevant angle is how content is consumed by systems that extract and synthesize. In that world, what used to be treated as “details” becomes critical:
- Semantic HTML and coherent hierarchy
- Structured data that’s well-scoped (without inflating markup)
- Avoiding late rendering and excessive JavaScript if you want content to be easy to extract
A Quick Checklist for Systems and Dev Teams
- A page-weight budget (especially on mobile) and alerts when exceeded
- Third-party inventory: what loads, when, and why
- Media discipline: modern formats, correct sizing, lazy loading, CDN strategy
- A clear WordPress builder decision: product choice or technical debt
- Real observability: CWV via RUM, plus cache/CDN and backend metrics
The chapter’s closing message, read through an ops lens, is blunt: the platform matters—but implementation is what decides outcomes.
FAQ
Which CMS tends to deliver better mobile Core Web Vitals in aggregate?
In the report, more controlled platforms tend to show stronger and more consistent gains on mobile, while highly extensible CMS ecosystems show wider variance between sites.
Why can two WordPress sites perform so differently?
Because performance usually depends more on hosting, theme, plugins, third parties, and page builders than on WordPress core itself. Flexibility enables excellent builds—and also very bloated ones.
What impacts CMS site performance more: HTML or resources?
Usually images and JavaScript. HTML is typically a small fraction of total transfer, while media, scripts, and third parties drive most of the weight and interaction latency.
How does LLM-based search change what matters for CMS sites?
It increases the value of structure, semantics, clarity, and good structured data, and it penalizes late rendering and heavy client-side dependency when content needs to be extracted reliably.