Qué es el TTFB y cuánto debería ser el tuyo
Publicado el 24 de julio de 2026 · Actualizado el 5 de agosto de 2026
Por Rubén Ortega · 12 años en soporte técnico y preventa de empresas de hosting (Abansys, Arsys, Nominalia) · Declaración de vínculos
📌 Datos clave
- Qué mide
- Milisegundos hasta el primer byte de respuesta
- Qué incluye
- DNS + conexión + TLS + generación de la página
- Bueno
- Menos de 200 ms
- Aceptable
- Entre 200 y 500 ms
- Problema
- Más de 800 ms
Respuesta rápida
El TTFB (Time To First Byte) son los milisegundos que pasan desde que el navegador pide una página hasta que recibe el primer byte de respuesta. Es lo que tarda el servidor en ponerse en marcha, antes de que se dibuje nada en pantalla.
Es la métrica que mejor separa el hosting del resto de la web. Todo lo que viene después —imágenes pesadas, JavaScript, fuentes— es responsabilidad de cómo está construida tu web. El TTFB es, en buena parte, responsabilidad de dónde está alojada.
Qué hay dentro de esos milisegundos
El TTFB no es una sola cosa. Son cuatro fases seguidas:
| Fase | Qué ocurre | De quién depende |
|---|---|---|
| DNS | Traducir el dominio a una IP | De tu proveedor de DNS |
| Conexión TCP | Abrir la conexión con el servidor | De la distancia física y la red |
| TLS | Negociar el cifrado de HTTPS | Del servidor y la distancia |
| Generación | PHP consulta la base de datos y monta el HTML | Del hosting y de tu web |
Las tres primeras suman entre 30 y 150 ms si el servidor está cerca. La cuarta es la que se dispara, y es donde de verdad se ve la diferencia entre un hosting bueno y uno malo.
Por eso un TTFB alto no siempre significa «hosting malo»: si estás midiendo desde otro continente, buena parte del número es distancia, no servidor.
Qué valores son razonables
Estas referencias asumen medición desde una ubicación cercana al servidor:
- Menos de 200 ms — bueno. Ahí están los servidores bien configurados con caché activa
- 200 a 500 ms — aceptable. Normal en compartido con carga real
- 500 a 800 ms — mejorable. Algo está haciendo más trabajo del necesario
- Más de 800 ms — hay un problema, y merece diagnóstico
Un aviso importante: el TTFB medio miente. Un servidor puede ir a 180 ms de madrugada y a 1.200 ms a las siete de la tarde. Lo que dice la verdad es el percentil 90: el valor por debajo del cual está el 90 % de las peticiones. Si tu p90 es cuatro veces tu mediana, tienes un problema de saturación en horas punta que la media esconde.
La medición que de verdad distingue
Medir el TTFB dos veces es lo que casi nadie hace, y es lo que separa un diagnóstico de una suposición: medir dos veces, con caché y sin caché.
- Con caché: pides la página normal. El servidor te da una copia ya montada. Es lo que
experimenta un visitante que llega a tu portada.
- Sin caché: pides la misma página forzando que se salte la caché. El servidor tiene que
ejecutar PHP y consultar la base de datos de verdad.
La diferencia entre ambos números lo dice todo:
| Con caché | Sin caché | Qué significa |
|---|---|---|
| Bajo | Bajo | El servidor va bien de verdad |
| Bajo | Alto | La caché lo tapa. Se notará en cuanto tengas carrito o área de usuario |
| Alto | Alto | Problema de infraestructura o de red |
Ese segundo caso es el interesante y el más común. Una web informativa puede ir perfecta porque casi todo se sirve cacheado. En cuanto montas una tienda —donde el carrito, la cuenta y el proceso de pago no se pueden cachear— aparece el TTFB real, y es otro.
Cómo medir el tuyo
Lo más simple, desde tu propio terminal:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s Total: %{time_total}sn" https://tudominio.com/
Y forzando saltar la caché con un parámetro único:
curl -o /dev/null -s -w "TTFB sin caché: %{time_starttransfer}sn" "https://tudominio.com/?nocache=$RANDOM"
Tres reglas para que la medición signifique algo:
- Repite tres veces y quédate con la mediana. Una sola medición no vale nada.
- Mide a distintas horas. El dato de las 4 de la mañana es el mejor caso, no el habitual.
- No midas desde el propio servidor. Sale mucho mejor de lo que ve un visitante real.
Si quieres el diagnóstico completo antes de tocar nada, está en por qué tu WordPress va lento y en cómo saber si el problema es tu hosting.
Qué hacer si el tuyo es alto
En orden de rentabilidad:
- Activa caché de página. Es lo que más baja el TTFB de un golpe: lo divide por cinco.
- Mira qué plugins consultan la base de datos en cada carga. Los de estadísticas, relacionados y sliders son los culpables.
- Comprueba la versión de PHP. Cada versión moderna es sensiblemente más rápida que la anterior, y muchos hostings dejan cuentas antiguas en versiones obsoletas.
- Revisa si estás tocando los límites del plan, en particular procesos concurrentes y memoria. Ahí el TTFB se dispara sin que tu web haya cambiado.
- Si sin caché sigue alto con una web limpia, el problema es el servidor.
Preguntas frecuentes
¿Qué es el TTFB?
Los milisegundos desde que el navegador pide una página hasta que recibe el primer byte. Incluye DNS, conexión, cifrado TLS y el tiempo que tarda el servidor en generar la página.
¿Cuánto TTFB es aceptable?
Menos de 200 ms es bueno, de 200 a 500 ms aceptable, y por encima de 800 ms hay un problema. Medido desde una ubicación cercana al servidor.
¿El TTFB alto es culpa del hosting?
No siempre. Si es alto solo sin caché, el servidor va justo o tu web hace demasiado trabajo. Si es alto también con caché, es infraestructura o red.
¿Afecta al posicionamiento?
El TTFB no es un factor de ranking por sí mismo, pero condiciona las métricas de experiencia de carga que sí se miden. Y afecta a lo que percibe el visitante, que es lo que decide si se queda.
Los rangos de referencia son los habituales del sector para alojamiento compartido medido cerca del servidor. Las mediciones propias de proveedores concretos se publicarán con su metodología y sus datos en bruto accesibles.