Skip to content

Todo para WordPress, el desarrollo web — y mucho más

⏱ Time to first byte: qué es TTFB y cómo mejorarlo en WordPress

⏱ Time to first byte: qué es TTFB y cómo mejorarlo en WordPress

Hizo clic en un enlace y el navegador se queda ahí, sin hacer nada. No carga la página, no hay indicador de progreso, solo una pantalla en blanco y espera. Esto no es su velocidad de internet ni JavaScript lento. Es el TTFB: el tiempo que tarda el servidor en responder a la primera solicitud.

El TTFB determina cuándo verán los usuarios algo en su pantalla. Con un TTFB lento, los visitantes se van antes de que su sitio siquiera empiece a renderizarse. Y a partir de 2025, Google incluye la capacidad de respuesta del servidor en sus señales de posicionamiento Core Web Vitals.

A continuación encontrará qué es realmente el TTFB, los cuatro componentes que lo conforman y cómo reducirlo a un nivel en el que su sitio entregue el primer byte más rápido de lo que un usuario tarda en parpadear.

💡 Resumen rápido:

  • Entienda qué es el TTFB y por qué cada segundo de esta demora se multiplica en cada acción del visitante.
  • Recorra la cadena de cuatro factores: DNS, servidor, plugins de WordPress y caché de HTML.
  • Compare cuatro escenarios con mediciones reales de Pingdom, desde 150 ms hasta unos catastróficos 4,2 segundos.
  • Active la caché de HTML y vea cómo un solo plugin reduce drásticamente el TTFB sin cambiar de proveedor de hosting.

Qué es el TTFB y por qué afecta a todo

La definición formal de Wikipedia: el TTFB es el tiempo transcurrido desde que se envía una solicitud HTTP hasta que se recibe el primer byte de la respuesta en el navegador del cliente. Incluye la latencia de la conexión del socket, el tiempo de transmisión de la solicitud y el tiempo de procesamiento del servidor.

En términos más sencillos: el TTFB es la pausa entre «hacer clic en un enlace» y «algo empieza a ocurrir en el sitio». En términos de videojuegos, es la latencia, el ping, el retraso antes de la primera respuesta. Los usuarios no ven cabecera, ni menú, ni indicador de carga, solo una pestaña vacía. Cuanto más larga sea esta pausa, mayor será la probabilidad de que cierren la pestaña.

Un matiz importante: el TTFB no solo afecta a la carga inicial de la página. Cada navegación interna, cada clic en un enlace del menú, cada clic en una imagen dentro de un artículo, es una solicitud HTTP independiente con su propio TTFB. Una mala puntuación se multiplica en cada acción del lector.

Cuatro factores que componen el TTFB

El TTFB no es una métrica única, sino una suma de retrasos en cada etapa de la cadena «usuario → sitio». Los cuatro eslabones funcionan de forma secuencial: si uno se ralentiza, el resultado final también lo hace. Examinemos cada uno.

DNS: el primer punto de control

El navegador no sabe dónde está ubicado físicamente su servidor hasta que el DNS convierte el dominio en una dirección IP. Los buenos servidores DNS con una red distribuida de nodos hacen esto en milisegundos, mientras que los deficientes añaden decenas o cientos de milisegundos a cada carga de página.

Mínimo práctico: use Cloudflare o un servicio similar con caché de DNS global. Tras la primera solicitud, la dirección permanece en caché y la latencia del DNS desaparece por completo para las solicitudes posteriores.

Servidor y PHP: lo que ocurre en el hosting

Cada solicitud a una página de WordPress no cacheada lanza el intérprete de PHP. El servidor carga el núcleo, el tema y los plugins activos, ejecuta su código y solo entonces entrega el HTML. Las versiones modernas de PHP gestionan este ciclo mucho más rápido que las versiones de hace una década, por no hablar de las ramas completamente obsoletas.

Dos parámetros del hosting determinan la velocidad: la versión de PHP y el tiempo de CPU asignado a su plan. Un hosting compartido barato con decenas de sitios en un mismo servidor y PHP desactualizado es un camino seguro hacia un TTFB superior a 1 segundo. Un hosting especializado en WordPress con PHP 8.2+ y caché integrada a nivel de servidor arroja cifras radicalmente distintas.

Plugins y tema de WordPress

WordPress ensambla las páginas a partir de docenas de archivos PHP, y cada plugin activo añade su código a este proceso. Diez plugins de calidad de desarrolladores reputados pueden apenas afectar al TTFB. Un solo plugin mal escrito que haga tres consultas extra a la base de datos en cada solicitud puede hundir la velocidad de todo su sitio.

He aquí un ejemplo de un conjunto de plugins sensato, todo lo necesario, nada superfluo:

Lista de plugins de WordPress en panel de administración con cantidad óptima

Y esta es ya una configuración potencialmente problemática. Varias docenas de plugins activos, y el servidor tiene que procesar cada uno al generar la página:

Lista larga de plugins de WordPress ralentizando respuesta del servidor

En la práctica, más de 30 plugins activos casi garantizan un TTFB alto, incluso en un buen hosting. La regla es simple: cada plugin debe realizar una tarea específica que no pueda resolverse de otra manera. Todo lo que esté ahí «por si acaso» debe eliminarse.

Caché de HTML: la palanca principal

El factor más potente de todos. Un plugin de caché como Cache Enabler guarda copias HTML listas de las páginas en el disco del servidor. Cuando llega una solicitud, el servidor web entrega un archivo estático, evitando toda la pila de PHP y WordPress.

El resultado: el servidor ya no necesita cargar el núcleo, el tema y los plugins para cada visitante. Solo el servidor web en sí (nginx o Apache) sirve el contenido directamente. Por eso la caché proporciona la reducción más significativa del TTFB, por factores y no por porcentajes. Explicamos por qué nginx es más eficiente que Apache para esta tarea en un artículo aparte.

TTFB en la práctica: cuatro escenarios

Pasemos a mediciones reales. A continuación se muestran los resultados de pruebas para distintas combinaciones de sitio y servidor, obtenidos mediante Pingdom Tools. Cada escenario muestra el TTFB tanto para las versiones sin caché como para las almacenadas en caché.

Sitio lento en un servidor lento

La peor combinación posible: un sitio con docenas de plugins y sin caché en un hosting compartido antiguo con PHP 5.4.

Resultado de prueba Pingdom para sitio lento en servidor lento

Ampliemos los detalles de la primera solicitud, donde puede ver al servidor pensando durante una eternidad:

Desglose de TTFB mostrando 4.2 segundos en Pingdom para sitio no optimizado

El TTFB es de 4,2 segundos. Cuatro segundos con el usuario mirando una pantalla en blanco antes de que el navegador reciba dato alguno. Súmele el tiempo de renderizado de la página, y el tiempo total de espera hasta que el sitio está listo alcanza fácilmente los siete segundos. Tener Cloudflare por delante no ayuda aquí: el problema es más profundo, a nivel del hosting y del código del sitio.

Sitio rápido en un servidor medio

Cambiamos las condiciones: un sitio con plugins mínimos, servidor en Apache con una versión de PHP estándar, sin caché.

Medición de TTFB de sitio rápido en hosting medio sin caché

Resultado: 521 ms. Ya es 8 veces mejor que el primer escenario. Medio segundo hasta el primer byte, aceptable para la mayoría de los sitios. Ahora activemos la caché:

TTFB de 152 ms tras activar caché en servidor medio

El TTFB baja a 152 ms. Incluso un hosting medio con una caché correctamente configurada ofrece resultados excelentes.

Sitio lento en un servidor rápido

La situación inversa: un servidor optimizado en Plesk con nginx y una versión de PHP estándar, pero un sitio saturado de plugins.

Servidor rápido no salva sitio lento sin caché

Sin caché, el servidor rápido igualmente tarda 1,29 segundos en procesar el sitio pesado. Un buen hosting mitiga pero no resuelve el problema de un WordPress mal optimizado.

Mismo sitio lento con caché mostró TTFB de 400 ms

Active la caché y el TTFB baja a 400 ms. Una diferencia de más del triple.

Sitio rápido en un servidor rápido

El escenario óptimo: un sitio ligero en un buen hosting.

Sitio rápido en servidor rápido sin caché

Sin caché, el servidor entrega el primer byte en menos de 500 ms. Añada la caché:

Mejor resultado de TTFB por debajo de 150 ms en servidor rápido con caché

Resultado: menos de 150 ms. Respuesta prácticamente instantánea.

Resumen de resultados

Los cuatro escenarios en un solo gráfico:

Gráfico comparativo de TTFB para cuatro combinaciones de sitio y hosting

La conclusión de estas mediciones es clara: el alojamiento importa, pero lo que usted hace con el sitio en sí afecta más al TTFB. Un servidor rápido con caché puede llevar incluso un sitio problemático a unos aceptables 400 ms, mientras que un servidor lento sin caché hunde hasta un WordPress ligero.

Cómo mejorar el TTFB: plan paso a paso

La optimización avanza de lo simple a lo complejo, desde lo que toma cinco minutos y produce el máximo impacto hasta los ajustes más finos.

Paso 1: active el caché HTML. Instale el Cache Enabler gratuito o un plugin de caché similar. Esta sola acción reduce el TTFB drásticamente en cualquier alojamiento. Sin exagerar, es el mayor retorno por minuto de esfuerzo en toda la optimización de WordPress.

Paso 2: revise su versión de PHP. En el panel de administración de su alojamiento o en cPanel, busque la configuración de la versión de PHP. Si hay una versión actual disponible (8.2 o más reciente), cámbiese a ella. Pasar de una rama obsoleta a una moderna acelera notablemente el procesamiento de cada solicitud. Antes de cambiar, asegúrese de que su tema y todos los plugins sean compatibles con la versión elegida.

Paso 3: audite sus plugins. Desactive todo lo que no esté en uso activo ahora mismo. Conserve solo los plugins que resuelvan una tarea específica. Todo lo demás debe eliminarse, no solo desactivarse. Los plugins que se guardan «para uso futuro» o «por si acaso» añaden código a cada solicitud, los use o no.

Paso 4: elija un tema rápido. El tema determina cuánto código PHP se ejecuta en cada carga de página. Los temas pesados con constructores visuales de páginas generan significativamente más trabajo del servidor que las soluciones minimalistas. Si una prueba de TTFB en una instalación limpia de WordPress (sin plugins, tema predeterminado) muestra un buen resultado, pero la puntuación cae drásticamente al activar su tema, el problema es el tema en sí.

Paso 5: evalúe su alojamiento. Si el TTFB aún supera los 500-800 ms después de los primeros cuatro pasos, la limitación está del lado del alojamiento. Un alojamiento WordPress especializado con nginx, PHP 8.2+ y caché del lado del servidor ofrece un nivel de respuesta fundamentalmente distinto. Al elegir, busque caché de objetos integrado (Redis o Memcached), que es el siguiente nivel después del caché HTML.

Video: TTFB de la teoría a los resultados

Vea un desglose visual del TTFB con mediciones en vivo antes y después de la optimización:

⁉️🤔 Preguntas frecuentes

¿Qué TTFB se considera bueno para WordPress?

Use los valores objetivo de Core Web Vitals de Google como guía: hasta 800 ms es aceptable, hasta 500 ms es bueno, hasta 200 ms es excelente. En la práctica, para un sitio WordPress con caché, el rango alcanzable es de 100-400 ms. Sin caché, incluso un sitio rápido rara vez baja de 400-500 ms.

¿Es obligatorio cambiar de alojamiento para mejorar el TTFB?

No siempre. El caché HTML reduce el TTFB drásticamente incluso en un alojamiento medio. Antes de migrar, active el caché, actualice PHP a una versión actual y limpie los plugins. Si el TTFB sigue por encima de 800 ms después de eso, entonces sí es momento de cambiar de alojamiento.

¿Por qué varía el TTFB de una medición a otra?

El TTFB se ve afectado por la carga de la CPU del servidor en el momento de la medición, la latencia de la red y la geografía del servidor de prueba. Tome una serie de 5 a 7 mediciones y use la mediana, no el primer valor aleatorio. Pruebe desde múltiples ubicaciones: un servidor en Europa puede mostrar un TTFB excelente desde Frankfurt, pero pobre desde Tokio.

¿Afecta el TTFB al posicionamiento en Google?

Sí, a partir de 2025, la capacidad de respuesta del servidor forma parte de Core Web Vitals como señal de posicionamiento. El impacto directo es moderado, pero el impacto indirecto es significativo: un TTFB alto aumenta la tasa de rebote, y una tasa de rebote alta perjudica directamente el posicionamiento.

¿Puedo medir el TTFB gratis?

Sí. Use Pingdom Tools, GTmetrix, PageSpeed Insights o WebPageTest. Un matiz importante: mida específicamente el TTFB (tiempo hasta el primer byte), no el tiempo total de carga de la página. En Pingdom, para ello necesita expandir los detalles de la primera solicitud al sitio.

Qué hacer con el TTFB ahora mismo

La principal conclusión de las mediciones anteriores: el caché HTML es la palanca más potente y simple. Un solo plugin reduce el TTFB drásticamente en cualquier alojamiento, y toma exactamente cinco minutos.

El orden de las acciones es el siguiente:

  • Si el TTFB > 1 segundo, comience con el caché y la actualización de PHP. Estos dos pasos proporcionan la mayor parte de la mejora posible.
  • Si el TTFB está entre 400 y 800 ms, una auditoría de plugins y del tema suele eliminar el retraso restante.
  • Si el TTFB está consistentemente por debajo de 200 ms, se encuentra en la zona óptima; mantenga el nivel actual.

Comience con un plugin de caché gratuito: instálelo, actívelo y ejecute una prueba a través de Pingdom Tools. Verá la diferencia de inmediato. ¿Cuál es su TTFB actual? Comparta sus cifras en los comentarios.