Durante años, elegir un CMS era casi una cuestión de comodidad: “que sea fácil de publicar”. En 2025, esa definición se queda corta. Los sistemas de gestión de contenidos se han convertido, literalmente, en infraestructura web: condicionan cómo se construyen los sitios, cómo se alojan, cuánto pesan y qué tal se comportan en móvil cuando llegan las prisas de tráfico… o cuando el equipo editorial empieza a crecer.
El capítulo CMS del Web Almanac 2025 de HTTP Archive (publicado el 15 de enero de 2026) pone números a esa transformación y, sobre todo, aterriza el debate con métricas que a ColorVivo le interesan especialmente: Core Web Vitals, Lighthouse, peso de página y composición de recursos. La lectura es clara: el CMS importa, sí, pero la implementación (hosting, plantillas, plugins, terceros, caché y disciplina operativa) suele decidir el resultado final.
El CMS ya no es “una opción”: es la web por defecto
La primera cifra marca el tono: en 2025, los sitios “CMS-driven” superan el 54% del total observado. Además, la tendencia sube de forma consistente desde 2021:
- En desktop, del 42% al 55% (2021→2025).
- En mobile, del 43% al 54% (2021→2025).
Esto tiene una lectura directa para administradores de sistemas y desarrolladores: si el CMS domina el parque instalado, entonces las decisiones de operación (caché, CDN, optimización de imágenes, control de scripts y gobierno editorial) pasan a ser una parte cada vez más grande del rendimiento “medio” de Internet.
El informe también observa diferencias por geografía. Por ejemplo, Italia aparece liderando la adopción en mobile con 51%, mientras Estados Unidos y Reino Unido rondan 49%. En el extremo opuesto se citan Indonesia (25%) y Brasil (32%). No es solo una curiosidad: suele reflejar qué pesa más en cada mercado (SaaS gestionado vs. open source autoalojado, ecosistemas locales, coste operativo, etc.).
WordPress sigue mandando… pero el crecimiento se reparte
En cuota de uso (mobile), el mapa general sigue con un protagonista claro: WordPress aparece alrededor del 64,3% de los sitios con CMS. Detrás, el crecimiento se distribuye entre varias plataformas: Shopify ronda el 7,3%, Wix el 5,2%, y Squarespace se mueve por debajo del 3%, al igual que Joomla. Webflow y Drupal quedan por debajo del 2% en cuota global.
El matiz importante no es solo quién lidera, sino cómo evoluciona el mercado: el informe remarca que WordPress mantiene la hegemonía, pero su crecimiento se desacelera (menos de 1 punto interanual). En vez de un “nuevo ganador único”, el avance se reparte en pequeños incrementos de varias plataformas. Resultado: un ecosistema más fragmentado, más especializado y, a menudo, más polarizado entre modelos “cerrados y gestionados” frente a modelos “abiertos y extensibles”.
El sesgo del Top 10.000: ahí mandan los CMS “de ingeniería”
Cuando se mira el top 10.000 (sitios de mayor tráfico), cambia el reparto. WordPress sigue fuerte, con alrededor del 58% del uso de CMS en ese segmento, pero destaca un dato: Drupal sube al 6–7%, muy por encima de su presencia global (~1%). Mientras tanto, Wix y Shopify casi no aparecen en ese nivel.
La lectura técnica es intuitiva: en la parte alta del ranking, pesan más las necesidades de workflows complejos, personalización profunda, gobernanza editorial y escalabilidad. No siempre es “el CMS más fácil”, sino el que encaja con equipos, procesos y deuda técnica asumible.
WordPress y la variabilidad: el “factor page builder” sigue explicándolo todo
Si WordPress domina, su rasgo más determinante no es solo la cuota: es la varianza. Dos sitios “WordPress” pueden ser tecnologías distintas según hosting, tema, plugins, estrategia de caché y, sobre todo, el “capa builder”.
El capítulo refleja una transición interesante en los page builders entre 2024 y 2025:
- Elementor baja aproximadamente de 56% a 43%.
- El Block Editor sube a alrededor del 18%.
- WPBakery cae de 21% a 13%.
- Divi baja de 14% a 10%.
- Beaver Builder se mantiene pequeño, en torno al 2%.
Para equipos de sistemas y devs, esto no es un debate estético: los builders influyen en DOM, CSS, JavaScript, comportamiento de carga, y por tanto en métricas como INP y en el “peso real” que termina pagando el usuario en móvil.
Core Web Vitals: los entornos controlados mejoran más rápido
En móvil, el informe muestra que los entornos más “gestionados” tienden a mejorar más rápido en el porcentaje de sitios con CWV “good” (2024→2025). Se citan avances aproximados como:
- Wix: +14%
- Duda: +11%
- Squarespace: +8%
- Joomla: +7%
- WordPress: +4%
- Drupal: +4%
- Weebly: −1%
En métricas concretas, el capítulo indica que en 2025 el 54% de los sitios logra un LCP “good”, y que las mejoras en INP son más modestas en general, señalando lo difícil que sigue siendo controlar JavaScript, tareas largas y dependencias de terceros.
La conclusión operativa es incómoda, pero útil: cuanto más “libre” es el ecosistema, más depende el rendimiento de lo que haga cada sitio.
Lighthouse: SEO alto, pero el móvil separa a los “bien afinados” del resto
En laboratorio (Lighthouse), las medianas 2025 remarcan una realidad que muchos equipos ven a diario: en desktop casi todo “parece decente”, pero en móvil aparecen las diferencias. Por ejemplo:
- Wix: 87 (desktop) / 64 (mobile)
- Duda: 81 / 57
- Webflow: 73 / 58
- WordPress: 63 / 41
- Shopify: 52 (mobile)
En SEO, las puntuaciones se mantienen altas y agrupadas (92–100), señal de que las bases están bastante estandarizadas. Donde se abre más hueco es en “Best Practices” y, en la práctica, eso suele traducirse en configuración, deuda técnica acumulada y control de recursos.
Peso de página: el problema casi nunca es el HTML
El capítulo recuerda que el peso medio en 2025 ronda 2,67 MB en desktop y 2,28 MB en mobile, por encima de lo que muchos equipos considerarían saludable. Y lo más accionable no es el número global, sino la composición: imágenes y JavaScript mandan.
El desglose de medianas por tipo de recurso (KB) lo deja claro:
- WordPress: imágenes 1.555 / 1.296 (D/M), JS 501 / 498, CSS 73 / 72, HTML 31 / 28
- Shopify: imágenes 1.643 / 1.495, JS 481 / 528, CSS 86 / 86, HTML 30 / 26
- Wix: imágenes 1.245 / 1.042, JS 458 / 459, CSS 61 / 60, HTML 28 / 25
- Squarespace: imágenes 1.544 / 1.313, JS 554 / 530, CSS 87 / 83, HTML 30 / 27
- Joomla: imágenes 1.593 / 1.432, JS 488 / 465, CSS 75 / 75, HTML 30 / 26
Dicho en clave de ColorVivo: optimizar HTML suele ser marginal. El retorno grande está en políticas de imágenes (formatos, tamaños, lazy, CDN y hábitos editoriales) y en poner el JavaScript a dieta (terceros, ejecución, long tasks e inventario real).
Checklist práctico para equipos que gestionan webs (sistemas + desarrollo)
- Presupuesto de peso (mobile): definir un techo realista y vigilarlo de forma continua.
- Imágenes como disciplina: formato moderno, tamaños correctos, responsive, CDN y reglas claras para el equipo editorial.
- JavaScript bajo control: inventario de terceros, carga condicional, y caza de tareas largas si INP sufre.
- WordPress sin autoengaño: decidir si el builder es parte del producto o una deuda; y medir su coste en DOM/JS.
- Observabilidad: si no se puede medir, no se puede mejorar (RUM, Core Web Vitals y métricas de caché/CDN/backend).
La idea final del informe, vista desde operaciones, es bastante directa: el CMS influye en el rendimiento, pero lo que determina el resultado es la implementación. En la “era CMS”, la sorpresa no desaparece por cambiar de plataforma: desaparece cuando hay control, métricas y disciplina.
Preguntas frecuentes
¿Qué CMS ofrece mejor rendimiento “por defecto” en móvil según Core Web Vitals?
Los datos sugieren que los entornos más controlados tienden a mejorar más rápido y con menos variabilidad, mientras que los CMS extensibles dependen mucho de cómo se implementen.
¿Por qué dos webs en WordPress pueden rendir tan distinto?
Por la combinación de hosting, tema, plugins, page builder, caché, CDN y scripts de terceros. WordPress permite resultados excelentes, pero también facilita el “crecimiento sin control” si no hay disciplina.
¿Qué optimizaciones suelen tener más impacto: tocar HTML o reducir recursos?
Reducir y optimizar imágenes y JavaScript suele dar mucho más retorno que tocar HTML, que normalmente representa una parte pequeña del peso total.
¿Cómo afecta la búsqueda con LLM al contenido generado por un CMS?
Gana importancia el HTML semántico, la jerarquía clara, los datos estructurados bien puestos y evitar dependencias excesivas de renderizado tardío o JavaScript pesado si se quiere que el contenido sea fácilmente extraíble.
