Haces clic en tu web, y antes de que aparezca nada, pasa un segundo largo en blanco. No es que las imágenes pesen mucho ni que el diseño sea complejo: es que el servidor tarda en contestar. A ese retardo se le llama TTFB (Time To First Byte), y es uno de los problemas de velocidad que más se ignoran porque no se ve en el diseño, se sufre en la espera. La buena noticia es que casi siempre tiene solución, y en WordPress las causas suelen repetirse.

Qué es el TTFB y por qué se dispara en WordPress

El TTFB mide el tiempo que pasa desde que el navegador pide una página hasta que recibe el primer byte de respuesta. Dentro de ese hueco caben tres cosas: la resolución del DNS y la conexión, el tiempo que el servidor dedica a generar el HTML y el viaje de vuelta de esa respuesta. En una web estática ese proceso es casi instantáneo; en WordPress, no.

El motivo es que WordPress es dinámico: cada visita ejecuta PHP, carga el tema, arranca todos los plugins activos y hace decenas o cientos de consultas a la base de datos antes de escribir la primera línea de HTML. Si algo de esa cadena va lento —un plugin pesado, una consulta mal resuelta, un servidor saturado—, el TTFB se dispara y arrastra a todo lo demás. Da igual lo optimizadas que estén tus imágenes: nada puede empezar a cargarse hasta que llega ese primer byte.

Cuánto TTFB es aceptable y cómo medir el tuyo

Como referencia práctica, por debajo de 200 ms es un resultado excelente, entre 200 y 500 ms es correcto para una web WordPress con hosting compartido decente, y por encima de 800 ms tienes un problema real que conviene atacar. Google no penaliza el TTFB como métrica aislada, pero sí influye de forma directa en el LCP, que sí es uno de los Core Web Vitals que cuentan para el posicionamiento y para la experiencia de tus visitas.

Para medirlo no necesitas herramientas de pago. Estas tres bastan:

• Las DevTools de tu navegador (pestaña Red, columna «Waiting for server response»). Es la medición más honesta porque parte de tu conexión real.
• PageSpeed Insights, que te da el «Tiempo de respuesta inicial del servidor» junto al resto de métricas.
• WebPageTest, si quieres comparar el TTFB desde distintas ubicaciones geográficas.

Un detalle importante: mide siempre con la caché vacía y también con la caché caliente, y hazlo tanto como visitante anónimo como con la sesión iniciada. Los resultados suelen ser muy distintos, y esa diferencia ya te dice mucho sobre dónde está el cuello de botella.

Las causas más habituales de un TTFB alto

Falta de caché de página

Es, con diferencia, la causa número uno. Sin caché, cada visita obliga a WordPress a reconstruir la página entera desde cero. Con una caché de página bien configurada, el servidor entrega un HTML ya preparado y el TTFB puede bajar de 900 ms a menos de 150 ms sin tocar una línea de código.

Plugins que se ejecutan en cada carga

No es una cuestión de cantidad, sino de qué hace cada plugin. Los sospechosos habituales son los constructores visuales pesados, los plugins de estadísticas que escriben en la base de datos en cada visita, los sliders con consultas complejas y cualquier extensión que llame a una API externa durante la carga: si ese servicio tarda, tu web espera con él.

Base de datos hinchada

Con los años, la tabla wp_options se llena de transitorios caducados y opciones autoload que se cargan en cada petición, y wp_postmeta acumula restos de plugins desinstalados. Una limpieza y optimización de la base de datos es de las tareas que mejor relación esfuerzo/resultado tiene.

Un WP-Cron desbocado

WordPress dispara sus tareas programadas aprovechando las visitas reales. Si tienes muchas tareas acumuladas, hay usuarios que pagan ese trabajo con su espera. Desactivar WP-Cron y sustituirlo por un cron real del servidor es una mejora silenciosa pero muy efectiva.

Versión de PHP antigua o recursos escasos

Seguir en PHP 7.4 cuando podrías estar en PHP 8.2 o superior te está costando rendimiento gratis, además de dejarte sin parches de seguridad. Y si tu plan de hosting va justo de CPU o memoria, ninguna optimización compensará esa falta de músculo.

Cómo reducir el TTFB paso a paso

El orden importa: empieza por lo que más impacto tiene y menos riesgo implica. Haz siempre una copia de seguridad antes de tocar nada y aplica los cambios de uno en uno, midiendo después de cada paso, para saber qué ha funcionado de verdad.

1. Activa una caché de página y comprueba que realmente se sirve en cacheado (busca la cabecera de caché en las DevTools). Verifica que el carrito, el checkout y las páginas de cuenta quedan excluidos.
2. Actualiza la versión de PHP a la más reciente que soporten tu tema y tus plugins, después de probarlo en un entorno de pruebas.
3. Activa OPcache y, si tu hosting lo permite, una caché de objetos con Redis o Memcached. En webs con muchas consultas, aquí está la mayor ganancia.
4. Audita los plugins con una herramienta de perfilado y desactiva o sustituye los que más tiempo de carga consumen.
5. Limpia la base de datos: transitorios caducados, revisiones antiguas, spam y opciones autoload innecesarias.
6. Sustituye WP-Cron por un cron del servidor ejecutándose cada 5 o 15 minutos.
7. Añade un CDN si recibes visitas de varios países: acorta la distancia física y reduce la latencia de la petición.
8. Vuelve a medir y documenta el antes y el después. Sin medición, estás adivinando.

Cuándo el problema no está en tu WordPress

A veces haces todo lo anterior y el TTFB apenas se mueve. Cuando eso pasa, el cuello de botella suele estar debajo de WordPress. En un hosting compartido, tu web convive con decenas de vecinos: si uno de ellos consume los recursos de la máquina, tú pagas la lentitud sin haber hecho nada mal. Es un buen momento para revisar si tu plan se te ha quedado pequeño y valorar el salto, como explicamos en nuestra comparativa de hosting compartido frente a VPS.

Hay dos señales que apuntan claramente al servidor: que el TTFB sea alto incluso en una página estática y cacheada, y que varíe muchísimo entre mediciones (300 ms ahora, 1,8 s dentro de cinco minutos). Esa inestabilidad casi nunca es culpa de tu tema. Si has llegado hasta aquí y sigues sin respuesta, en nuestro servicio de optimización de velocidad para WordPress hacemos exactamente este diagnóstico: medir, aislar la causa y aplicar solo lo que de verdad mueve la aguja.

Preguntas frecuentes

¿Un TTFB alto perjudica mi posicionamiento en Google?

El TTFB no es una métrica de posicionamiento por sí sola, pero sí forma parte del LCP, que sí lo es. Un servidor lento retrasa el inicio de toda la carga, así que empeora tus Core Web Vitals de forma indirecta y, sobre todo, aumenta el porcentaje de visitas que se van antes de ver nada.

¿Un plugin de caché soluciona el TTFB por sí solo?

Lo mejora mucho en las páginas cacheadas, pero no cubre todos los escenarios. El carrito, el checkout, las áreas privadas y las búsquedas internas no se pueden cachear, y ahí el TTFB depende de tu PHP, tu base de datos y tu hosting. La caché es el primer paso, no el único.

¿Cuánto puedo llegar a bajar el TTFB de mi web?

Depende del punto de partida. En webs que nunca se han optimizado es habitual pasar de más de un segundo a menos de 300 ms combinando caché, PHP actualizado y limpieza de base de datos. Si ya estás por debajo de 400 ms, las mejoras serán menores y probablemente pasen por cambiar de plan de hosting.

¿Prefieres que lo revisemos nosotros? En MantPress medimos tu TTFB, localizamos la causa real y la corregimos sin que tengas que tocar nada: échale un vistazo a nuestro servicio de optimización de velocidad WordPress o a nuestros planes de mantenimiento, donde el rendimiento se vigila mes a mes.