Qué es el TTFB (Time To First Byte) y cómo medirlo paso a paso

Si has abierto PageSpeed Insights o GTmetrix y te has topado con las siglas TTFB, seguramente te preguntes qué es exactamente y por qué a un consultor SEO le importa tanto. La respuesta corta: el Time To First Byte es la métrica que mejor refleja lo rápido que responde tu servidor, y es lo primero que reviso cuando quiero saber si el problema de velocidad de una web está en el alojamiento o en otra parte.

En esta guía te explico qué es el TTFB, qué influye en un TTFB lento, cómo medirlo con herramientas gratuitas (y con la consola del navegador) y cómo empezar a mejorarlo. Sin humo y con los umbrales que de verdad usa Google.

¿Qué es el TTFB o Time To First Byte?

El TTFB (Time To First Byte, «tiempo hasta el primer byte») es el tiempo que transcurre desde que el navegador solicita una página hasta que recibe el primer byte de la respuesta del servidor web. Dicho de otra forma: no mide cuánto tarda en cargar la web entera, sino cuánto tarda el servidor en empezar a contestar.

Una analogía sencilla: imagina que pides en una cafetería. El TTFB no es el tiempo hasta que te terminas el café, sino el tiempo desde que haces el pedido hasta que el camarero te trae la primera taza. Cuanto antes llegue ese primer sorbo, mejor va todo lo demás.

Y ese «todo lo demás» es la clave: el TTFB precede a cualquier otra métrica de carga. Nada se puede pintar en pantalla hasta que el navegador recibe el HTML. Por eso, cada milisegundo que se pierde en el TTFB se arrastra al resto de la carga.

Qué fases se incluyen dentro del TTFB

El TTFB no es un único paso, sino la suma de varias fases que ocurren antes de que llegue ese primer byte. Según la documentación oficial de Google, se compone de:

• Tiempo de redirecciones (si las hay).
• Arranque del service worker, si el sitio usa uno.
• Resolución de DNS (traducir el dominio a una IP).
• Negociación de conexión TCP y TLS (el «handshake» y el cifrado HTTPS).
• La solicitud en sí, hasta que llega el primer byte de respuesta.

Entender esto es importante porque un TTFB alto puede venir de la red (DNS, latencia, distancia física al servidor) o del procesamiento del servidor (lo que tarda en generar la página). No siempre es lo mismo, y saber diferenciarlo es media batalla ganada.

¿Qué influye en un TTFB lento?

Un TTFB lento casi nunca tiene una única causa. Estas son las más habituales que me encuentro auditando webs, sobre todo en WordPress:

• Hosting o servidor saturado. El clásico. Planes compartidos muy baratos con overselling («recursos ilimitados» que no existen) responden lento en horas punta. Un síntoma muy típico: el TTFB mejora solo de madrugada, cuando hay menos actividad; Yo trabajo con Lucus.
• Software del servidor web poco eficiente. Servidores como Apache o IIS suelen dar peores tiempos que Nginx o LiteSpeed, que gestionan las peticiones de forma más eficiente.
• Versión de PHP antigua. Seguir en PHP 7.x cuando podrías estar en PHP 8 penaliza, y el efecto es mayor cuanto más pesada y compleja es la web.
• Falta de caché de página (o una caché mal configurada). Sin caché, el servidor tiene que reconstruir la página en cada visita, procesando PHP y consultando la base de datos una y otra vez.
• Web demasiado compleja. Demasiados plugins, consultas lentas a la base de datos o código innecesario aumentan el tiempo de procesamiento.
• Distancia física y red. Si tu servidor está lejos del usuario o la ruta de red es mala, la latencia sube el TTFB aunque el servidor sea rápido.

Un detalle poco conocido: algo tan simple como activar la compresión GZIP o Brotli en la transferencia puede reducir de forma notable el tiempo necesario para servir ese primer byte.

¿El TTFB influye en el SEO?

Sí, aunque conviene matizarlo, porque hay bastante confusión con este tema.

Empecemos por lo importante: el TTFB NO es un Core Web Vitals. Los tres Core Web Vitals son LCP (Largest Contentful Paint), INP (Interaction to Next Paint) y CLS (Cumulative Layout Shift). Y Google no usa el TTFB directamente como señal de posicionamiento.

Entonces, ¿por qué le doy tanta importancia? Por dos motivos:

1. Es una métrica de diagnóstico y «arrastra» a las que sí cuentan. El TTFB es la base sobre la que se construye todo lo demás. Como precede al FCP y al LCP, cada milisegundo que ahorras en TTFB es un milisegundo que ahorras en esas métricas de renderizado. Puedes aprobar los Core Web Vitals con un TTFB regular, pero si tu LCP va justo, arreglar el TTFB suele ser la acción de mayor impacto para desatascarlo.

2. Afecta al crawl budget y al rastreo. Un TTFB lento hace que el bot de Google gaste más recursos (y más tiempo) en rastrear cada URL, desperdiciando presupuesto de rastreo. De hecho, muchas webs que «creen» tener un problema de SEO por una mala puntuación en PageSpeed en realidad tienen un problema de indexación o rastreo provocado, directa o indirectamente, por un TTFB lento.

Un indicador indirecto muy útil: en Google Search Console, dentro de «Estadísticas de rastreo», lo ideal es que el «Tiempo medio de respuesta» no supere los 500 ms. No es exactamente el TTFB, pero cuando el TTFB empeora, ese tiempo medio suele subir también.

¿Cómo afecta el TTFB a la experiencia de usuario (UX)?

Aquí es donde, en mi opinión, el TTFB pega más fuerte. Si al usuario no le empieza a cargar nada, se va a «Atrás» y se abre el siguiente resultado de Google. Y el rebote, a la larga, no ayuda.

Además, hay un efecto multiplicador que muchos ignoran: la latencia amplifica el TTFB. Un TTFB base de 0,2 segundos medido desde una buena conexión de fibra puede convertirse en 2 segundos para un usuario que navega con datos móviles y poca cobertura. Y si tu TTFB de partida ya son 2 segundos, con ese mismo factor puede irse a 4. El bot de Google rara vez sufre esto, pero tus usuarios reales lo viven a diario.

Por eso mido siempre pensando en el usuario en movilidad, no solo en el resultado «de laboratorio».

¿Cuál es un buen TTFB?

No hay un número mágico universal, porque depende del tipo de web y de su complejidad. Pero sí hay referencias sólidas:

• Guía oficial de Google: un TTFB ≤ 0,8 s (800 ms) se considera bueno; entre 0,8 y 1,8 s necesita mejora; y > 1,8 s deficiente. Google recomienda apuntar a que el percentil 75 de tus usuarios entre dentro del umbral «bueno».
• Referencia de rastreo (Search Console): por debajo de 500 ms de tiempo medio de respuesta.
• Objetivo exigente (WPO): para una experiencia realmente rápida, muchos consultores marcamos el listón bastante más abajo, en torno a 200–300 ms como tope antes de empezar a preocuparnos.

Mi criterio práctico: si tu TTFB pasa de forma habitual de los 300 ms, ya merece la pena investigar. Y si toca segundos, es prioritario, porque está ralentizando la carga de todo lo demás.

Ojo con un matiz que sí importa: una web renderizada en servidor puede permitirse un TTFB algo más alto y aun así tener buen FCP y LCP, mientras que una SPA (aplicación de una sola página que se completa con JavaScript) necesita el TTFB más bajo posible. Los umbrales son una guía, no un dogma.

Cómo medir el TTFB de tu sitio web

Vamos a la parte práctica. Hay dos grandes familias de herramientas: las de laboratorio (miden en un entorno controlado, ideales para hacer pruebas al hacer cambios) y las de campo (miden a usuarios reales). Lo suyo es combinar ambas. Estas son las que uso.

1. Herramientas de desarrollador de Google Chrome (mi favorita)

Es la forma más rápida y precisa de medir en laboratorio, y funciona en cualquier navegador basado en Chromium.

1. Abre la web en modo incógnito (así las extensiones no falsean el resultado).
2. Abre las herramientas de desarrollador con Control + Mayús + I (o botón derecho → Inspeccionar).
3. Ve a la pestaña Network / Red y recarga la página.
4. Haz clic sobre la primera petición (el documento HTML) y busca el desglose de tiempos: ahí verás el Waiting for server response, que es el TTFB.

La gran ventaja es que Chrome te deja emular distintas conexiones (3G, 4G) y dispositivos, así que puedes ver el TTFB tal y como lo sufre un usuario en móvil con mala cobertura, no solo con tu fibra.

2. Pingdom Tools, GTmetrix y WebPageTest

Herramientas online que miden desde servidores repartidos por el mundo, útiles para ver la latencia desde distintas ubicaciones:

• Pingdom Tools: desglosa muy bien los tiempos (de hecho, por dentro se apoya en la tecnología de Chrome). Suele ofrecer localización en Europa; si mides una web española, elige Frankfurt, porque dentro de Europa apenas hay latencia. Su punto débil es que la versión gratuita a veces falla o mete cola de espera.
• GTmetrix y WebPageTest: dos clásicos para medir el TTFB junto al resto de métricas de rendimiento.

3. PageSpeed Insights de Google

Introduces la URL y te da el TTFB junto a los Core Web Vitals, tanto con datos de laboratorio como con datos de campo (usuarios reales de CrUX, si tu web tiene tráfico suficiente). Mi consejo: mira siempre también el detalle en móvil, no solo en escritorio.

4. Con la línea de comandos (curl)

Si te manejas en la terminal, curl te da el TTFB de una URL al instante:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://tudominio.com

Devuelve el tiempo hasta que empieza la transferencia. Rápido y sin florituras.

5. Medir el TTFB en JavaScript (para perfiles técnicos)

Si quieres capturar el TTFB de usuarios reales e integrarlo en tu analítica, puedes usar la Navigation Timing API con un PerformanceObserver:

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');
  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({ type: 'navigation', buffered: true });

O, más cómodo, con la librería oficial web-vitals de Google:

import { onTTFB } from 'web-vitals';
onTTFB(console.log);

Nota técnica: con la llegada de las 103 Early Hints, el navegador puede recibir «primeros bytes» antes de la respuesta final. Chrome ha ido cambiando cómo mide esto (lo movió en Chrome 115 y lo revirtió en Chrome 133), así que lo importante es saber qué mide exactamente la herramienta que uses para comparar de forma coherente.

Cómo mejorar el TTFB (primeros pasos)

Medir sin actuar no sirve de nada. No hay una solución única, porque depende de dónde venga el problema, pero estos son los frentes por los que suelo empezar:

• Hosting de calidad. Es lo más determinante. Un buen alojamiento, con recursos reales y cercano a tu audiencia, resuelve la mayoría de los casos. Si tu web mejora sola de madrugada, tu problema es el servidor.
• Servidor web eficiente: pásate a Nginx o LiteSpeed si estás en Apache/IIS.
• PHP actualizado: subir a PHP 8 suele dar una mejora notable frente a versiones antiguas.
• Caché de página. Fundamental en CMS como WordPress: evita reprocesar PHP y consultar la base de datos en cada visita. Con una buena caché, un TTFB de 800 ms puede bajar a cifras de 100 ms.
• Compresión GZIP o Brotli activada en la transferencia.
• Vigila los recursos del servidor: si la CPU o la RAM viven por encima del 80 %, ahí tienes tu cuello de botella.

¿Un CDN mejora el TTFB?

Depende del tipo de CDN. Un CDN tradicional no mejora el TTFB, porque el TTFB se mide en el HTML inicial, que se sirve desde tu servidor de origen. Pero un CDN que funciona como proxy inverso y cachea el HTML (el caso típico es Cloudflare) sí puede mejorarlo, porque se coloca entre el visitante y tu servidor y sirve la página cacheada desde el nodo más cercano. Así que la respuesta honesta es: sí, pero solo bajo esa configuración concreta.

Preguntas frecuentes sobre el TTFB

Conclusión

El TTFB es de esas métricas que dan mucha información con poco esfuerzo: si está mal, tienes el cuello de botella localizado y sabes por dónde empezar; si está bien, te deja el campo despejado para trabajar el resto del WPO. Por eso es lo primero que reviso antes de tocar nada más.

Medirlo está al alcance de cualquiera con las herramientas de Chrome o PageSpeed Insights. Interpretarlo y arreglarlo de raíz (distinguir si el problema es el servidor, PHP, la caché o la red) es donde suele hacer falta experiencia.

Si has medido tu TTFB, ves que se te va de los 300 ms y no tienes claro de dónde viene, puedo echarle un vistazo y decirte exactamente dónde está el problema. Escríbeme y lo vemos sin compromiso en

Rogama Informática

Apasionado de la montaña, del SEO y la programación a partes iguales, llevo más de 20 años trabajando en distintos sectores, pero siempre enfocado a la web, si quieres saber más de mí, sigue el enlace.