TTFB frente a tiempo de respuesta frente a latencia

Qué significa cada término

La latencia de red, que a menudo se reporta como tiempo de ida y vuelta, es el tiempo que pasa un paquete viajando hasta el servidor y de vuelta sin ningún trabajo de aplicación de por medio. La fija la distancia física, el número de saltos y la calidad de la ruta. Nada de lo que hagas en tu código la cambia.

El tiempo hasta el primer byte (TTFB) se mide desde el momento en que el cliente inicia la petición hasta que le llega el primer byte de la respuesta. Ese tramo contiene la consulta DNS, la conexión TCP, la negociación TLS, el tiempo que la petición pasa en tránsito, lo que sea que haga el servidor para producir una respuesta, y el trayecto de vuelta. Por eso el TTFB siempre es mayor que un solo tiempo de ida y vuelta, normalmente varias veces mayor.

El tiempo de respuesta es el más laxo de los tres. La mayoría de las herramientas de monitorización lo usan para el tiempo total de completar la petición, desde el primer paquete hasta el último byte del cuerpo. Algunas herramientas lo usan como sinónimo de TTFB. Antes de comparar dos números etiquetados como "tiempo de respuesta", comprueba en qué momento detuvo cada herramienta el cronómetro.

Cómo se mide cada uno

La latencia viene de un eco ICMP, que es lo que envía ping, o de cronometrar el saludo TCP cuando ICMP está bloqueado. El TTFB y el tiempo total vienen del propio cliente HTTP. Una sola llamada a curl imprime todos los límites:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Cada valor es acumulativo desde el inicio de la petición, así que se leen como límites y no como duraciones. Resta el anterior para obtener la duración de una etapa.

Qué número te está mostrando tu herramienta

Cada herramienta reporta un tramo distinto de la misma petición, que es el motivo habitual de que dos mediciones de un mismo sitio no coincidan:

• ping reporta solo la latencia de ida y vuelta, sin incluir ningún trabajo del servidor
• curl -w reporta cada límite de los listados arriba, lo que lo convierte en la referencia cuando los números no coinciden
• Las herramientas de desarrollador del navegador muestran el TTFB como la etapa de espera de una petición, separada de la etapa de descarga que va debajo
• Lighthouse y PageSpeed reportan el tiempo de respuesta del servidor, que es el TTFB de la petición del documento
• Los monitores de uptime reportan un tiempo de respuesta cuya definición varía según el producto, e incluye el establecimiento de la conexión desde donde se ejecutó la comprobación
• La monitorización de usuarios reales reporta el TTFB de campo, agregado entre visitantes reales en redes reales

Qué aspecto tiene un buen número

La latencia está limitada por la geografía. Menos de 30 ms es normal dentro de una misma área metropolitana, de 50 a 100 ms entre continentes cercanos, y de 150 a 250 ms entre continentes. Una ruta que mide muy por encima de la distancia sugiere un camino malo y no un servidor lento.

Para el TTFB, web.dev trata 800 ms o menos como bueno y cualquier cosa por encima de 1,8 segundos como deficiente, mientras que la auditoría de tiempo de respuesta del servidor de Lighthouse empieza a fallar por encima de 600 ms. Apunta a menos de 600 ms para la petición del documento y trata 200 ms como el objetivo para cualquier cosa cacheada o servida de forma estática.

El tiempo de respuesta total depende del tamaño de lo que estés enviando, así que no hay una cifra universal. Mide tu propia línea base en un día normal y trata el cambio respecto a ella como la señal, no el número absoluto.

Leer las diferencias

Los números individuales importan menos que la distancia entre ellos, porque cada diferencia señala a un subsistema distinto:

• El TTFB menos la latencia de ida y vuelta es más o menos lo que el servidor pasó pensando. Si esa es la parte grande, el problema es el código de la aplicación, una consulta lenta o una caché fría
• La conexión menos la consulta DNS es un tiempo de ida y vuelta para el saludo TCP. Si es mucho mayor que tu latencia medida, la ruta de red está congestionada o mal enrutada
• El TLS menos la conexión es el coste del saludo, normalmente uno o dos tiempos de ida y vuelta extra, y un valor grande señala problemas de cadena de certificado o de reanudación de sesión
• El total menos el TTFB es el tiempo de transferencia. Si eso domina, la respuesta es demasiado grande o la conexión es demasiado lenta, y ningún ajuste del servidor ayudará
• La consulta DNS por sí sola debería ser unos pocos milisegundos una vez en caché. Una consulta constantemente lenta es un problema del resolutor o del servidor de nombres autoritativo, no del servidor web

La misma lectura funciona al revés cuando solo una ubicación es lenta. Un tiempo de reflexión del servidor igual en todas partes, con la diferencia viviendo enteramente en la latencia y la transferencia, significa que el servidor está bien y la ruta no. Ejecuta la comprobación desde varios sitios antes de tocar la aplicación.

Medirlo en un solo sitio

Para ver estos números de una página sin montarlos a mano, ejecuta la prueba de velocidad de página, que carga la página desde una ubicación externa y desglosa la carga en sus etapas. La guía del tiempo de respuesta del servidor cubre la misma medición desde la línea de comandos. Una sola ejecución solo te informa de ese momento, así que si el número importa, pon una comprobación programada sobre él: HostTracker mide el tiempo de respuesta en cada comprobación desde más de 300 puntos de control en 158 ciudades, que es lo que convierte una lectura en una línea base contra la que detectar una regresión. Hay más definiciones en la sección de conceptos de monitorización.