Qué medimos exactamente, y por qué el TTFB
El TTFB (Time To First Byte) es el tiempo que pasa desde que el navegador pide la página hasta que el servidor empieza a devolverla. Lo elegimos por una razón práctica: es el suelo de todo lo demás. Puedes optimizar imágenes, diferir JavaScript y limpiar el CSS, pero nada de eso empieza a ocurrir hasta que llega el primer byte. Un TTFB de 2 segundos es un retraso de 2 segundos aplicado a todas las métricas de Core Web Vitals a la vez.
Y es una medida honesta para comparar sitios distintos: no depende del tamaño de la página ni de cuántas fotos tenga, solo de cuánto tarda el servidor en decidir qué enviar. Es exactamente donde un CMS con muchas capas encima se nota.
El método, para que lo puedas replicar
- Muestra: 280 webs de negocios reales de un mismo ámbito geográfico (Comunidad de Madrid), obtenidas de directorios públicos. De ellas, 242 respondieron y 38 no contestaron o dieron error de conexión.
- Medición: una petición HTTP a la portada desde una conexión española, midiendo el tiempo hasta el primer byte. Detección de plataforma a partir de las señales del propio HTML y de las cabeceras.
- Estadístico: usamos la mediana, no la media. La media queda destrozada por unos pocos casos extremos — hubo una web con 14.070 ms de TTFB, catorce segundos. La mediana describe lo que se encuentra un visitante normal.
- Anonimato: los nombres, teléfonos y URLs de los negocios analizados no se publican ni se publicarán. Solo los agregados.
El resultado principal
De las 242 webs que respondieron, 145 eran WordPress (el 59,9%) y 97 no lo eran. La diferencia entre los dos grupos no es sutil:
| Grupo | Webs | Mediana | Percentil 90 | Máximo |
|---|---|---|---|---|
| WordPress | 145 | 1.014 ms | 3.391 ms | 14.070 ms |
| Sin WordPress | 97 | 269 ms | 966 ms | 3.279 ms |
| Todas | 242 | 443 ms | 2.635 ms | 14.070 ms |
3,8 veces más lento de mediana. Pero el dato que más nos llamó la atención no es la mediana, sino el percentil 90: el 10% peor de los WordPress tarda más de 3,4 segundos solo en empezar a responder. En el grupo sin WordPress, ese mismo 10% peor está por debajo del segundo. Es decir: la peor web sin WordPress de la muestra iría más rápido que una web de WordPress media-mala.
La explicación no es WordPress. Es lo que se le monta encima
Conviene decirlo claro porque es fácil sacar la conclusión equivocada: WordPress no es lento por naturaleza. Un WordPress con una plantilla ligera, buen hosting y caché puede responder por debajo de 300 ms sin despeinarse. Lo que este estudio mide no es el potencial de WordPress, sino cómo está montado WordPress en la realidad.
Y ahí aparece el segundo dato: de esos 145 WordPress, 107 usaban un page builder. El 73,8%.
| Page builder | Webs | % de los WordPress |
|---|---|---|
| Elementor | 56 | 38,6 % |
| WPBakery | 29 | 20,0 % |
| Divi | 19 | 13,1 % |
| Beaver Builder | 2 | 1,4 % |
| Oxygen | 1 | 0,7 % |
| Sin page builder | 38 | 26,2 % |
Un page builder resuelve un problema real — permite montar páginas sin escribir código — y a cambio cobra un precio en cada visita: normalmente carga el CSS y el JavaScript de todos sus componentes, uses dos o cincuenta, y añade capas de procesamiento en el servidor antes de generar el HTML. Tres de cada cuatro WordPress de esta muestra están pagando ese precio.
Lo que encontramos de paso
La herramienta comprobaba más cosas además del tiempo de respuesta. Sobre el total de 280 webs analizadas:
| Problema detectado | % de webs |
|---|---|
| Ninguna imagen en formato moderno (WebP/AVIF) | 49,6 % |
| Sin datos estructurados (Schema.org) | 27,9 % |
| Sin meta description | 27,5 % |
| Sin etiquetas Open Graph | 27,5 % |
| La portada no tiene ningún H1 | 23,9 % |
| Sin etiqueta canonical | 22,1 % |
| Versión de WordPress visible públicamente | 20,7 % |
| No se encuentra sitemap.xml | 14,3 % |
| No responde o error de conexión | 13,6 % |
| No existe robots.txt | 9,3 % |
Que una de cada dos webs no use ni una sola imagen en formato moderno es, en términos de peso transferido, dinero tirado en cada visita. Y que el 23,9% de las portadas no tenga un H1 significa que casi un cuarto de estos negocios no le está diciendo a Google, en el sitio donde Google mira primero, a qué se dedica.
Qué hacer con esto si tu web es un WordPress
La conclusión útil no es "migra de WordPress". Es más matizada y más barata:
- Mide tu TTFB antes de tocar nada. Si estás por debajo de 300 ms, tu problema de velocidad — si lo tienes — está en otro sitio y este artículo no va contigo.
- Si estás por encima de 800 ms, el orden importa: primero hosting y caché, después el page builder, y solo al final las imágenes. Cambiar imágenes cuando el servidor tarda 2 segundos en contestar es pintar la fachada de una casa sin cimientos.
- Si el page builder es la causa, rehacer solo las plantillas más visitadas en HTML/CSS limpio suele dar más resultado que cualquier plugin de optimización, y no obliga a rehacer la web entera.
- Plantéate el cambio de base solo si el coste de mantener lo actual ya supera al de rehacerlo. Lo desarrollamos con números en WordPress o desarrollo a medida.
¿Y tu WordPress, en qué lado de la tabla está?
Medimos tu TTFB, detectamos si el page builder te está costando segundos y te decimos qué se arregla ajustando y qué solo se arregla rehaciendo. Con números, antes de proponerte nada.
Auditoría técnica de WordPressLa honestidad del dato
Tres límites que conviene conocer, porque un estudio que no los cuenta no merece confianza:
- Una sola medición por web. El TTFB varía entre peticiones; una segunda medida podría mover casos individuales. Con 242 webs, la mediana del grupo es estable, pero no lo es el dato de ninguna web concreta.
- Ámbito geográfico y sectorial acotado. Son negocios de un área concreta de la Comunidad de Madrid, sobre todo pymes y comercio local. No representa al comercio electrónico grande ni a webs corporativas de multinacionales.
- Correlación, no causalidad. Los WordPress de la muestra son más lentos, pero también tienden a estar en hostings compartidos más baratos. No podemos separar del todo el efecto del CMS del efecto del hosting — y sospechamos que ambos suman.
Aun con esos límites, la diferencia es demasiado grande para ser ruido: 3,8× de mediana y un percentil 90 tres veces peor no se explica por variabilidad de medición.
Preguntas frecuentes
¿Es WordPress lento por naturaleza?
No. Un WordPress bien montado responde por debajo de 300 ms. Este estudio no mide el potencial de WordPress, mide cómo está montado en la realidad: en la muestra, el 73,8% de los WordPress usaba un page builder, que es la fuente habitual de la diferencia.
¿Qué es el TTFB y por qué importa?
Es el tiempo que tarda el servidor en empezar a enviar la página. Importa porque todo lo demás ocurre después: hasta que no llega el primer byte, el navegador no puede pintar nada. Retrasa todas las métricas de Core Web Vitals a la vez.
¿Cuánto debería tardar mi web en responder?
Google recomienda por debajo de 800 ms, y por debajo de 200 ms se considera bueno. En las 242 webs medidas la mediana global fue de 443 ms, pero el percentil 90 se disparó a 2.635 ms.