Durante años, hablar de CMS era casi sinónimo de hablar de “facilidad para publicar”. En 2025, esa idea se queda corta. Los CMS se han convertido en la infraestructura por defecto de buena parte de la web y, con ello, en un factor que condiciona decisiones técnicas que a veces pasan desapercibidas: desde el modelo de hosting y los defaults hasta el peso real de las páginas, la estabilidad visual o la capacidad de un sitio para rendir bien en móvil sin depender de heroicidades.
El capítulo CMS del Web Almanac 2025 (HTTP Archive) aterriza el debate con métricas. No intenta coronar a un “CMS ganador”, sino describir un mercado maduro y fragmentado donde la experiencia final se decide, sobre todo, en la implementación: temas, plugins, builders, terceros, caché, CDN y disciplina operativa.
El CMS ya no es “una opción”: es el estándar de la web
La primera cifra marca el tono del informe: en 2025, los sitios “CMS-driven” superan el 54% del total observado. Y la tendencia viene de lejos.
Tabla 1 — Adopción de CMS (tendencia 2021→2025)
| Plataforma | 2021 | 2025 |
|---|---|---|
| Desktop | 42% | 55% |
| Mobile | 43% | 54% |
En otras palabras: la web “sin CMS” no está creciendo; se está encogiendo en proporción. Para equipos de sistemas, esto también significa que el rendimiento medio de internet está cada vez más ligado a decisiones típicas de operación: configuración de cachés, políticas de medios, control de JavaScript, y cómo se gobierna el contenido cuando el editor tiene muchas palancas.
El informe también muestra contrastes por geografía: Italia aparece en cabeza (mobile 51%), mientras EE. UU. y Reino Unido rondan 49%. En el otro extremo, Indonesia (25%) y Brasil (32%) cierran el grupo.
WordPress domina… pero el crecimiento ya no “se lo lleva todo”
En cuota de uso (mobile), WordPress sigue siendo el gran referente. Pero el dato interesante ya no es solo la magnitud, sino el cambio de dinámica: el crecimiento se desacelera y el resto del mercado araña cuota en pequeños incrementos que, sumados, dibujan un ecosistema más repartido.
Tabla 2 — Cuota de CMS (mobile, 2025)
| CMS | Cuota |
|---|---|
| WordPress | 64,3% |
| Shopify | 7,3% |
| Wix | 5,2% |
| Squarespace | < 3% |
| Joomla | < 3% |
| Webflow | < 2% |
| Drupal | < 2% |
El capítulo remarca que no hay un “asesino de WordPress” único: Shopify se mueve en torno al 7,3–7,8%, Wix alrededor del 5% y Squarespace cerca del 3%. Es decir: más fragmentación y más elección, pero sin una ola que desplace al líder.
Cuando el tráfico importa, cambian los CMS que aparecen
Otra lectura muy útil para perfiles de sistemas y desarrollo llega con el “sesgo del top”. En el top 10.000, WordPress concentra ≈58% del uso de CMS, y Drupal sube a ≈6–7%, muy por encima de su cuota global. A ese nivel, plataformas tipo Wix o Shopify prácticamente no aparecen: el tráfico alto suele traer requisitos de ingeniería, personalización y workflows complejos que empujan hacia stacks distintos.
WordPress y la varianza: el “builder” como multiplicador
Si WordPress es el gran CMS, su rasgo técnico más determinante no es la cuota: es la varianza. En el mundo real, dos WordPress pueden parecer tecnologías distintas según hosting, tema, plugins, caché, terceros y, sobre todo, page builder.
El capítulo refleja una transición: los builders tradicionales pierden peso y el enfoque “block-native” gana terreno, aunque el legado sigue siendo enorme.
Tabla 3 — Page builders en WordPress (2024→2025)
| Builder | 2024 | 2025 |
|---|---|---|
| Elementor | ~56% | ~43% |
| Block Editor | n/d | ~18% |
| WPBakery | ~21% | ~13% |
| Divi | ~14% | ~10% |
| Beaver Builder | n/d | ~2% |
Para un sysadmin, esto suele traducirse en un fenómeno conocido: la misma plataforma, con “configuraciones editoriales” distintas, puede disparar el DOM, aumentar el JavaScript y empeorar métricas como INP sin que nadie haya “cambiado el servidor”.
Core Web Vitals: los entornos controlados mejoran más deprisa
En móvil, el informe muestra que las plataformas con entorno más gestionado y defaults más cerrados tienden a mejorar más rápido en porcentaje de sitios con CWV “good”.
Tabla 4 — Mejora interanual de CWV “good” (mobile, 2024→2025)
| Plataforma | Δ YoY (aprox.) |
|---|---|
| Wix | +14% |
| Duda | +11% |
| Squarespace | +8% |
| Joomla | +7% |
| WordPress | +4% |
| Drupal | +4% |
| Weebly | −1% |
En métricas concretas, el patrón se repite: las mejoras existen, pero no se propagan igual en ecosistemas donde cada sitio “es un mundo”.
- LCP (mobile): en 2025, 54% de sitios logra un LCP “good”.
- CLS (mobile): Wix destaca con mejoras fuertes, mientras otros se mueven poco; Weebly cae.
- INP (mobile): mejoras más modestas, señal de que la “responsividad” sigue siendo un problema compartido cuando hay mucho JavaScript y demasiados terceros.
La lectura operativa es clara: cuando la plataforma controla más cosas, las mejoras llegan a más sitios. Cuando el CMS es extensible y flexible, los avances dependen de decisiones locales.
Lighthouse: SEO alto, pero el móvil separa a los “bien afinados” del resto
El laboratorio (Lighthouse) no es lo mismo que datos de usuarios reales, pero sirve para ver implementaciones “típicas” bajo condiciones comparables. En rendimiento, el salto entre plataformas es notable, especialmente en móvil.
Tabla 5 — Lighthouse Performance (mediana 2025)
| CMS | Desktop | Mobile |
|---|---|---|
| Wix | 87 | 64 |
| Duda | 81 | 57 |
| Webflow | 73 | 58 |
| Shopify | n/d | 52 |
| WordPress | 63 | 41 |
| Joomla | n/d | 40 |
En SEO, casi todos quedan altos (≈92–100), señal de que los básicos están bastante “baked in”. Donde se abren más diferencias es en Best Practices, y ahí el informe vuelve a apuntar hacia un tema recurrente: calidad de implementación, deuda acumulada y configuración de recursos.
Peso de página: el cuello de botella no es HTML, son imágenes y JavaScript
El capítulo recuerda un dato incómodo: el peso medio en 2025 ronda 2,67 MB en desktop y 2,28 MB en móvil. Por encima de lo que muchos considerarían saludable para una experiencia rápida y accesible.
Y, sobre todo, insiste en el reparto: el HTML rara vez es el problema. El coste real está en imágenes y JavaScript: formatos, tamaños, carga diferida, inventario de terceros, tareas largas e impacto en interacción.
En la práctica, esto empuja a una conclusión que los equipos técnicos suelen aprender “a golpes”: optimizar sin un presupuesto de peso y sin observabilidad (RUM + CWV + métricas de caché/CDN) es más intuición que ingeniería.
Nuevas APIs del navegador: ayudan, pero no hacen magia
El informe señala APIs emergentes que pueden mejorar percepción de velocidad y navegación (Speculation Rules, View Transitions, métricas como LoAF para entender mejor INP). El matiz es importante: estas APIs pueden suavizar parte de la varianza y mejorar “cómo se siente” un sitio… pero no compensan páginas pesadas ni una cadena de terceros sin control.
CMS en la era de los buscadores con LLM: estructura, semántica y eficiencia
Otra derivada cada vez más relevante es la “consumición” del contenido por sistemas que extraen y sintetizan. En ese contexto, gana valor lo que durante años se trató como detalle:
- HTML semántico y jerarquía coherente.
- Datos estructurados bien puestos (sin inflar el markup).
- Evitar depender de renderizado tardío y exceso de JavaScript si se quiere contenido fácilmente extraíble.
Checklist rápido para sistemas y desarrollo
- Presupuesto de peso (especialmente en móvil) y alertas si se supera.
- Inventario de terceros: qué carga, cuándo y por qué.
- Política de medios: formatos modernos, tamaños correctos, lazy-load y CDN.
- Decisión explícita sobre builders en WordPress: producto o deuda.
- Observabilidad real: CWV con RUM, más métricas de caché, CDN y backends.
El mensaje final del capítulo, leído con mentalidad de operaciones, es bastante directo: la plataforma importa, sí; pero lo que decide el resultado es la implementación.
Preguntas frecuentes
¿Qué CMS suele dar mejores Core Web Vitals en móvil según datos agregados?
En el informe, las plataformas más “controladas” tienden a mostrar mejoras mayores y resultados más consistentes en móvil, mientras que CMS muy extensibles presentan más varianza entre sitios.
¿Por qué dos webs con WordPress pueden rendir tan distinto?
Porque el rendimiento suele depender más de hosting, tema, plugins, terceros y uso de page builders que del “core” en sí. La flexibilidad permite grandes resultados… y también grandes desastres.
¿Qué pesa más en el rendimiento de un sitio con CMS: HTML o recursos?
Normalmente pesan más imágenes y JavaScript. El HTML suele ser una fracción pequeña del total, mientras que imágenes, scripts y terceros pueden disparar tanto el peso como la latencia de interacción.
¿Cómo afecta el auge de buscadores con LLM a las webs hechas con CMS?
Aumenta la importancia de estructura, semántica, claridad y datos estructurados, además de reducir dependencia de renderizado tardío. Un contenido rápido de extraer y bien etiquetado tiende a “viajar” mejor en sistemas de síntesis.
