El TTFB (Time to First Byte, o tiempo hasta el primer byte) es el tiempo que transcurre desde que el navegador envía una solicitud HTTP hasta que recibe el primer byte de la respuesta del servidor. En términos simples: mide cuánto tarda tu servidor en empezar a responder. Un TTFB bajo significa que el servidor reacciona rápido; uno alto indica que algo en el backend, la red o la configuración está frenando todo.
En este artículo encontrarás exactamente qué compone el TTFB, qué valores se consideran buenos, qué factores lo elevan y cómo diagnósticarlo.
Qué mide exactamente el TTFB
El TTFB no es solo el "tiempo del servidor". Dentro de ese número se acumulan tres fases distintas:
- Tiempo de conexión: incluye la resolución DNS, el establecimiento de la conexión TCP y el handshake TLS (si el sitio usa HTTPS).
- Tiempo de procesamiento del servidor: el tiempo que el servidor tarda en generar la respuesta — consultas a la base de datos, lógica de negocio, renderizado de plantillas, etc.
- Tiempo de red (ida y vuelta): la latencia física entre el servidor y el navegador del usuario.
El navegador no puede pintar nada en pantalla hasta recibir ese primer byte. Por eso el TTFB es la puerta de entrada de toda la experiencia de carga.
Qué valores de TTFB se consideran buenos
Google define los umbrales dentro de las métricas de experiencia de usuario así:
| Calificación | TTFB |
|---|---|
| Bueno | Menos de 800 ms |
| Necesita mejora | 800 ms – 1 800 ms |
| Deficiente | Más de 1 800 ms |
Para sitios modernos y bien optimizados, un TTFB por debajo de 200 ms es perfectamente alcanzable cuando el usuario está geográficamente cerca del servidor o del nodo CDN que le sirve el contenido.
Qué factores elevan el TTFB
Un TTFB alto casi siempre tiene una causa identificable. Las más frecuentes son:
Calidad del hosting
El factor con mayor impacto individual. Un plan de hosting compartido sobrecargado, con decenas de sitios compitiendo por los mismos recursos de CPU y memoria, puede tener un TTFB de 1–3 segundos simplemente por saturación. Migrar a un VPS o a un plan con recursos garantizados suele ser la mejora más inmediata.
Consultas lentas a la base de datos
Cada vez que una página dinámica (WordPress, Joomla, aplicaciones a medida) necesita datos, ejecuta consultas SQL. Si esas consultas no tienen índices adecuados, procesan millones de filas o se encadenan sin optimización, el servidor no puede responder hasta que terminen. El resultado: TTFB disparado.
Ausencia de caché de página completa
Sin caché, cada solicitud obliga al servidor a reconstruir la página desde cero — PHP, base de datos, plantilla — para cada visitante. Con caché de página completa activo, el servidor sirve un archivo HTML estático pre-generado en milisegundos, sin tocar la base de datos.
Distancia física entre servidor y usuario
La luz viaja rápido, pero no infinitamente. Un usuario en Ciudad de México consultando un servidor en Europa añade 100–200 ms de latencia solo por física. Una red de distribución de contenido (CDN) soluciona esto colocando copias en servidores más cercanos a cada región.
Handshake TLS lento o no optimizado
HTTPS requiere un proceso de negociación (handshake) que añade uno o dos viajes de red antes de que empiece a fluir información. Configuraciones antiguas de TLS (TLS 1.0/1.1), certificados mal encadenados o la ausencia de session resumption pueden inflar este tiempo innecesariamente.
Cómo medir el TTFB de tu sitio
Existen varias formas de obtener el dato:
- Chrome DevTools: pestaña Network → haz clic en cualquier recurso → sección "Timing". El valor "Waiting (TTFB)" es exactamente lo que buscas.
- Google PageSpeed Insights: lo reporta dentro de la sección de diagnósticos bajo el nombre "Tiempo de respuesta inicial del servidor".
- WebPageTest: muestra el TTFB por recurso y permite probar desde distintas ubicaciones geográficas para separar latencia de red de tiempo de procesamiento.
- Search Console (CrUX): el informe de Core Web Vitals incluye datos de TTFB reales de tus usuarios, no simulaciones.
Para obtener una imagen fiel, prueba desde al menos dos ubicaciones — una cercana al servidor y una lejana — y en distintos momentos del día para detectar picos de carga.
Cómo reducir el TTFB paso a paso
Una vez identificada la causa, las soluciones más efectivas son:
- Activa la caché de página completa. En WordPress, plugins como WP Rocket o W3 Total Cache con la opción de caché de disco sirven páginas estáticas en menos de 50 ms. En aplicaciones a medida, Varnish o Nginx FastCGI cache cumplen la misma función.
- Optimiza las consultas a la base de datos. Usa
EXPLAINen MySQL/MariaDB para identificar consultas lentas. Añade índices en columnas filtradas conWHEREy evita losSELECT *innecesarios. - Usa una CDN. Para usuarios dispersos geográficamente, una CDN puede reducir el TTFB percibido de 800 ms a menos de 100 ms sirviendo desde el nodo más cercano.
- Actualiza a TLS 1.3. Reduce el handshake a un solo viaje de red frente a los dos del TLS 1.2. La mayoría de los servidores modernos lo soportan con un cambio de configuración.
- Escala el hosting. Si el servidor está saturado de CPU o memoria, ninguna optimización de código resolverá el problema de raíz. Un plan de mayor capacidad o un servidor dedicado puede ser el paso necesario.
Para profundizar en más métricas y técnicas relacionadas, visita el archivo de artículos sobre rendimiento web donde encontrarás guías sobre LCP, CLS y caché explicadas paso a paso.
Si prefieres que un experto diagnostique el TTFB de tu sitio y te entregue un plan de acción concreto, el equipo de elenlace.com realiza auditorías de rendimiento con recomendaciones priorizadas por impacto.
Conclusiones clave
- El TTFB mide el tiempo entre la solicitud del navegador y el primer byte de respuesta del servidor.
- Se compone de tres fases: conexión de red, procesamiento del servidor y latencia de red.
- Google considera "bueno" un TTFB inferior a 800 ms; menos de 200 ms es excelente.
- Las causas más frecuentes son hosting sobrecargado, consultas lentas, ausencia de caché y distancia al servidor.
- La caché de página completa y una CDN son las palancas más efectivas para reducirlo rápidamente.
¿Tu TTFB supera los 800 ms y no sabes por dónde empezar? Contacta a elenlace.com para una revisión técnica y recibe recomendaciones concretas adaptadas a tu stack.
Preguntas frecuentes
¿El TTFB afecta directamente el SEO?
Sí, de forma indirecta pero real. El TTFB contribuye al Largest Contentful Paint (LCP), que sí es un Core Web Vital con peso en el ranking de Google. Un TTFB alto retrasa el inicio de la carga visible y hace casi imposible tener un LCP bueno.
¿Puedo mejorar el TTFB sin cambiar de hosting?
En muchos casos sí. Activar la caché de página completa, optimizar consultas lentas a la base de datos y añadir una CDN puede reducir el TTFB significativamente sin migrar el servidor. Si el problema es saturación de recursos del plan, tarde o temprano el cambio de hosting será inevitable.
¿Cuál es la diferencia entre TTFB y FCP?
El TTFB mide cuándo llega el primer byte de la respuesta — el servidor ha empezado a responder, pero el navegador todavía no ha pintado nada. El FCP (First Contentful Paint) mide cuándo el navegador pinta el primer texto o imagen visible. El FCP siempre ocurre después del TTFB.
¿Un TTFB de 800 ms es malo para todos los sitios?
No de igual manera. Para un usuario con servidor en la misma región, 800 ms indica un problema claro en el backend. Para un usuario al otro lado del mundo sin CDN, parte de ese tiempo es latencia de red inevitable. Por eso conviene medir desde distintas ubicaciones antes de concluir dónde está el problema.
Compara proveedores
Otros proveedores y guías que vale la pena comparar:
