Una web puede tener imágenes optimizadas, poco JavaScript y una buena caché de navegador y, aun así, tardar demasiado en empezar a responder. El Time to First Byte (TTFB) ayuda a separar ese retraso inicial del resto de la carga: mide cuánto tiempo pasa hasta que empieza a llegar el primer byte de la respuesta.
En WordPress, un TTFB alto puede estar relacionado con red, alojamiento, caché de página, PHP, consultas de base de datos, llamadas externas o trabajo excesivo durante cada petición. Antes de cambiar de hosting o instalar otro plugin, conviene medir y localizar la fase que realmente añade tiempo.
Qué mide el TTFB
web.dev define TTFB como el tiempo entre el inicio de la navegación y el momento en que comienza a llegar la respuesta. Esa medida puede incluir redirecciones, resolución DNS, establecimiento de conexión, negociación TLS y el tiempo que el servidor necesita para empezar a responder.
Por eso el TTFB no es sinónimo de «tiempo de PHP» ni permite culpar directamente al hosting. Una cifra alta indica que el comienzo de la respuesta está tardando; el diagnóstico debe determinar en qué parte.
web.dev utiliza como guía aproximada un TTFB de 0,8 segundos o menos para muchos sitios y considera deficiente superar 1,8 segundos. También aclara que TTFB no es una Core Web Vital. Su importancia está en que ocurre antes de métricas posteriores como FCP y LCP.
Cómo medirlo sin sacar conclusiones precipitadas
Una sola medición desde tu ordenador no representa a todos los visitantes. Conviene combinar pruebas de laboratorio con datos de campo cuando haya volumen suficiente.
- Chrome DevTools: el panel Network permite revisar el tiempo de espera de la petición del documento HTML.
- PageSpeed Insights y CrUX: cuando existe información de usuarios reales, ayudan a contextualizar el rendimiento observado en campo.
- WebPageTest: permite repetir pruebas desde ubicaciones y condiciones controladas.
- Pruebas con y sin caché: comparar una respuesta cacheada con otra que necesita ejecutar WordPress ayuda a distinguir capas.
No compares cifras obtenidas con metodologías distintas como si fueran idénticas. La ubicación del test, una conexión nueva, el estado de la caché o una redirección previa pueden modificar el resultado.
Primero separa red y backend
El objetivo es responder a una pregunta sencilla: ¿el retraso aparece antes de llegar al servidor o mientras WordPress genera la respuesta?
Si el DNS, la conexión o TLS consumen una parte importante del tiempo, revisa infraestructura de red, CDN, redirecciones y proximidad geográfica. Si la conexión se establece con rapidez pero el servidor tarda en entregar cabeceras, el foco pasa al backend.
En un WordPress dinámico, ese backend puede incluir carga del núcleo, tema, plugins, consultas SQL, peticiones HTTP externas y generación del HTML.
Comprueba la caché de página
La documentación de WordPress explica que servir páginas estáticas desde caché reduce el procesamiento necesario en el servidor. En una web mayoritariamente pública y poco dinámica, comparar una respuesta cacheada con una sin caché puede revelar cuánto trabajo evita esa capa.
Si quieres profundizar en las diferencias entre caché de página, objetos, navegador y CDN, consulta la guía de caché en WordPress.
No des por buena una configuración solo porque el plugin indique «caché activa». Comprueba las cabeceras, repite peticiones y verifica si la página realmente se está sirviendo desde la capa esperada.
Revisa PHP, plugins y llamadas externas
Cuando una petición no puede resolverse desde caché, WordPress ejecuta código. Un plugin puede añadir consultas costosas, ejecutar lógica en todas las páginas o esperar la respuesta de un servicio externo. El tema también puede incorporar trabajo innecesario durante la generación del documento.
Para localizar la causa, cambia una variable cada vez y mide de nuevo. En un entorno de staging puedes comparar plugins, registrar tiempos y revisar qué peticiones externas se ejecutan durante la carga. Evita desactivar componentes al azar en producción.
Si una incidencia ya está produciendo errores o tiempos de espera, la guía de registros de errores en WordPress puede ayudarte a relacionar el síntoma con el momento exacto de la petición.
Base de datos y opciones autoload
WordPress consulta la base de datos para construir contenido y configuración. Tablas grandes no implican por sí solas un problema, pero consultas lentas, índices inadecuados, opciones autoload excesivas o datos abandonados pueden añadir tiempo de procesamiento.
La optimización debe partir de evidencia. Borrar registros sin saber quién los utiliza puede provocar una avería y no garantiza una mejora de TTFB. Para esta parte tienes una guía específica sobre optimizar la base de datos de WordPress.
Hosting: cuándo tiene sentido sospechar de la infraestructura
El alojamiento importa, pero debe evaluarse después de separar caché, aplicación y red. CPU saturada, memoria insuficiente, almacenamiento lento, límites de procesos, PHP mal dimensionado o una base de datos sobrecargada pueden aumentar la latencia del backend.
Una señal útil es que varias páginas simples presentan un retraso similar incluso después de revisar la aplicación. Otra es que el TTFB empeore bajo concurrencia mientras el consumo de recursos alcanza límites. En ese punto conviene revisar métricas del servidor en lugar de limitarse a repetir pruebas de PageSpeed.
TTFB, LCP y Core Web Vitals
Un TTFB alto puede retrasar todo lo que ocurre después, pero reducirlo no garantiza por sí solo un buen LCP. La imagen principal todavía puede ser pesada, descubrirse tarde o competir con CSS y JavaScript.
Por eso conviene tratar el TTFB como una señal de base y después revisar las métricas centradas en la experiencia del usuario. Puedes continuar con las guías de LCP en WordPress y Core Web Vitals.
Orden práctico de diagnóstico
- Mide varias veces y anota ubicación, dispositivo y estado de caché.
- Comprueba si existen redirecciones antes de la URL final.
- Separa tiempos de conexión de tiempo de respuesta del servidor.
- Compara una petición cacheada con otra que ejecute WordPress.
- Revisa PHP, plugins, tema y llamadas externas en staging.
- Analiza consultas y opciones de base de datos si el backend sigue siendo lento.
- Correlaciona las pruebas con CPU, memoria, procesos y base de datos del servidor.
- Valida después LCP, INP y CLS: mejorar el primer byte no termina el trabajo.
Este orden evita una reacción habitual: instalar optimizadores o cambiar de proveedor antes de saber dónde se está consumiendo el tiempo.
¿Tu WordPress tarda en empezar a cargar?
Dentro del servicio de mantenimiento WordPress puedo revisar caché, backend y rendimiento para separar síntomas de causas antes de aplicar cambios.
Fuentes oficiales
- web.dev: Time to First Byte (TTFB).
- web.dev: optimizar TTFB.
- WordPress Developer Resources: Optimization.
- WordPress Developer Resources: Cache.
Fuentes consultadas el 17 de octubre de 2026. Los umbrales de TTFB son orientativos y deben interpretarse junto con la forma en que el sitio entrega su contenido y con datos de usuarios reales cuando estén disponibles.
