TTFB: qué es, por qué importa y cómo reducirlo en una web moderna

El Time to First Byte (TTFB) se ha convertido en uno de los termómetros más fiables para medir la “sensación de rapidez” de una página. Aunque no es un Core Web Vital, influye directamente en métricas como LCP (Largest Contentful Paint), en el rendimiento percibido por el usuario y, en última instancia, en conversión y SEO (rastreos más eficientes). Este artículo explica, en clave periodística y práctica, qué abarca realmente el TTFB, cómo medirlo bien y cuáles son las palancas de mejora más efectivas para sitios de contenido, ecommerce y APIs.

Qué mide exactamente el TTFB

El TTFB es el tiempo que transcurre desde que el navegador envía una petición hasta que recibe el primer byte de respuesta. Incluye, por tanto:

DNS (resolución del dominio).
Conexión (TCP o QUIC) y handshake de TLS.
Envío de la petición y espera en cola en el servidor.
Trabajo de la aplicación (rutas, cachés, consultas a BD, plantillas).
Salida del primer byte hacia el cliente.

Si cualquiera de esos tramos se “atasca” —RTT elevado, handshakes costosos, colas en el servidor, consultas lentas— el TTFB se dispara.

Referencias útiles (sitios globales):

En la misma región: p50 ≤ 200–300 ms.
Entre continentes: p50 ≤ 500–700 ms.
Señal de alerta: un p95 que duplique o triplique el p50 suele indicar cuellos de botella (colas, GC, cold starts, bloqueo en BD o peering pobre).

Medir sin autoengañarse

Los expertos recomiendan combinar tres capas:

RUM (Real User Monitoring): el TTFB visto por navegadores reales, segmentado por país, operador (ASN) y dispositivo.
Pruebas sintéticas: robots desde varias regiones, comparando CDN vs origen, HTTP/2 vs HTTP/3 y situaciones de caché fría y caliente.
Telemetría del servidor: workers ocupados, colas de aceptación, slow logs de base de datos, hit ratio de caché, tiempos de TLS, CPU en espera, pausas de GC.

El waterfall del navegador ayuda a localizar dónde se “come” el tiempo: si lo largo está en conectar/TLS, el problema es de red o cifrado; si lo largo es waiting (TTFB), suele estar en la aplicación/origen.

Dónde están las mejoras de mayor impacto

1) Poner un buen borde delante (CDN o reverse proxy)

Terminar TLS 1.3 en el borde y habilitar HTTP/2 y HTTP/3/QUIC.
Anycast y buen peering para acercarse físicamente y en red a los usuarios.
Origin shielding: un PoP “escudo” que habla con el origen y reduce el fan-out.
Caché agresiva cuando sea legal:
- Estáticos con max-age=31536000, immutable y nombres versionados.
- HTML anónimo con TTL corto (30–120 s) y stale-while-revalidate para ocultar la revalidación.
Personalización en el borde: fragmentos (ESI/edge includes) o edge compute para no invalidar la caché completa.

Efecto: el primer byte puede salir del PoP cercano en decenas de milisegundos, eliminando viajes innecesarios al origen.

2) Reducir costes de handshake y transporte

TLS 1.3, reanudación y 0-RTT (sólo para GET idempotentes).
HTTP/3 (mejor recuperación de pérdidas en móvil/wifi) y HTTP/2 (multiplexación).
Mantener keep-alives; activar OCSP stapling; preferir ECDSA.
En orígenes: sopesar BBR como control de congestión; NIC y MTU bien afinados.

3) Eliminar redirecciones en cadena y envíos a la región equivocada

Compactar http → https → www → locale → final a un salto; HSTS ayuda.
Verificar que el GeoDNS y el CDN no envían a usuarios europeos a PoPs de EE. UU. (añade 80–120 ms).

4) Acelerar el origen (cuando hay que tocarlo)

Servidor web (Nginx/Apache) con workers y keep-alive bien dimensionados; HTTP/2/3 activos.
Tiempo de ejecución: pooling correcto (PHP-FPM/Node/JVM), OPcache/JIT, dependencias minimalistas.
Base de datos: caché (Redis/Memcached), índices en rutas calientes, conexión en pool, adiós a consultas N+1.
Serverless: provisioned concurrency o warmers para endpoints con SLO de TTFB, bundles pequeños y conexiones persistentes a backends.

5) Caché de HTML sin romper la personalización

HTML completo para anónimos; datos privados por fetch cliente o fragmentos en el borde.
Evitar claves por usuario salvo necesidad (explota la caché).
Diseñar APIs cachéables (ETag/Last-Modified) y colapsar peticiones duplicadas en el borde.

6) Control de colas y sobrecarga

Mejor encolar y servir 503 con Retry-After que saturar workers y degradar TTFB para todos.
Circuit breakers ante dependencias lentas; autoscaling guiado por p95 de latencia y profundidad de cola, no sólo por CPU.

7) No romper la caché

Vary sólo en lo imprescindible; normalizar query strings; quitar rastreadores del cache key cuando sea legal.
Consistencia en headers y host; claves de caché estables.

Un plan rápido en 14 días

Día 1–2: línea base

RUM por país/ASN/dispositivo (p50/p95 TTFB) y sintéticos multi-región (CDN vs origen, H2 vs H3, frío vs caliente).
Métricas del servidor: workers, colas, BD p95, hit ratio.

Día 3–5: red y cifrado

TLS 1.3, reanudación, OCSP, HTTP/2 + HTTP/3.
Quitar cadenas de redirecciones y activar HSTS.
Confirmar PoP más cercano y peering correcto.

Día 6–9: caché

Estáticos inmutables y versionados.
HTML anónimo con TTL corto + stale-while-revalidate.
Origin shielding activo y monitorizado.

Día 10–12: origen/app

Redis en rutas de lectura, índices críticos, pools dimensionados.
Afinar PHP-FPM/Node/JVM para evitar tanto el thrash como la inanición.

Día 13–14: guardarraíles

Autoscaling por p95 y colas.
Alertas por TTFB p50/p95 en geos clave y canaries sintéticos para login/checkout.

Repetir mediciones; el objetivo es bajar p50 y, sobre todo, cerrar la brecha con p95.

Casos de uso: cómo aterriza

Medios y blog: HTML anónimo con TTL corto y stale-while-revalidate; imágenes y JS/CSS en CDN con hash y TTL largo.
Ecommerce: categorías y landing cacheadas; PDP con fragmentos (opiniones/recomendaciones) y datos privados vía fetch.
APIs: GET con ETag y Cache-Control público; colapsar peticiones iguales en el borde; rate limit y backoff bien definidos.
Serverless: cold starts bajo control (concurrencia provisionada); validación de sesión en el borde cuando sea viable.

Señales de éxito

Descenso del TTFB p50/p95 por región; aumento del hit ratio; caen las peticiones al origen por 1.000 visitas.
Mejoras en LCP y, a menudo, en conversión y tasa de rastreo.
Menos “brownouts” durante mantenimientos del proveedor.

Preguntas frecuentes

¿El TTFB es lo mismo que el LCP?
No. TTFB termina cuando llega el primer byte; LCP mide cuándo se renderiza el elemento principal visible. Reducir TTFB suele ayudar a LCP, pero son métricas distintas.

¿Basta con activar HTTP/3 para mejorar el TTFB?
Ayuda (mejora handshakes y pérdidas en móvil/wifi), pero si el cuello está en aplicación/BD, la ganancia será limitada. Hay que atacar red + cifrado + app + caché.

¿Puedo cachear HTML sin perder personalización?
Sí: cachea la parte pública y añade fragmentos o datos privados por cliente. Evita claves de caché por usuario salvo que sea imprescindible.

¿Cuál es un objetivo razonable de TTFB?
De referencia: 200–300 ms p50 en la misma región y 500–700 ms entre continentes, con p95 dentro de 2–3× del p50. Dependerá del público y del caso de uso.

Tras poner CDN, mi TTFB subió. ¿Por qué?
Suele ser caché desactivada, redirecciones extra o PoP equivocado por GeoDNS. Revisa reglas de caché, rutas canónicas y proximidad real del PoP.

Conclusión

El TTFB es un indicador compuesto que engloba DNS, transporte, TLS, servidor y aplicación. La ruta más rápida para mejorarlo combina un borde bien afinado (HTTP/2/3, TLS 1.3, shielding, caché inteligente) con un origen disciplinado (pools, BD e índices, fragmentos cacheados). Medir desde la perspectiva del usuario, reducir la latencia de cola y optimizar región por región es la receta para que una web “se sienta” instantánea.