El tiempo hasta el primer byte se utiliza a menudo para medir la rapidez con que un servidor web responde a una petición. Los servicios habituales de pruebas web informan de ello. Cuanto más rápido, mejor será el servidor web (en teoría). Pero la teoría no es especialmente buena.
Wikipedia define el tiempo hasta el primer byte como "la duración desde que el usuario virtual hace una solicitud HTTP hasta que el primer byte de la página es recibido por el navegador". Pero, ¿de qué informan en realidad los sitios de pruebas de páginas web más conocidos? Para averiguarlo, creamos un servidor de prueba que inserta retrasos en la respuesta HTTP y comprobamos lo que se mide realmente. La respuesta fue muy sorprendente y demostró que el TTFB no es una medida útil.
Cuando un navegador solicita una página desde un servidor web, envía la petición en sí y algunas cabeceras que especifican cosas como el formato aceptable para la respuesta. El servidor responde con una línea de estado (por lo general HTTP/1.1 200 OK, que indica que la página está disponible), seguida de más cabeceras con información sobre la página y finalmente el contenido de la página.
El servidor de pruebas de TTFB de Cloudflare funciona de una manera ligeramente diferente. Cuando recibe una solicitud, envía la primera letra de HTTP/1.1 200 OK (la H) y luego espera 10 segundos antes de enviar el resto de los encabezados y la propia página. (Puedes acceder al código del servidor TTFB aquí; está escrito en Go).
Si solicitas a WebPageTest que descargue una página desde el servidor de Cloudflare TTFB, te dan la siguiente sorpresa. WebPageTest informa del tiempo hasta el primer byte a partir del momento en que se recibe la H (y no cuando la propia página se envía realmente). La espera de 10 segundos hace que esto sea obvio.
En gomez se informa exactamente de la misma cifra.
El TTFB del que se informa no es el momento del primer byte de datos de la página, sino el primer byte de la respuesta HTTP. Son cosas muy diferentes, porque los encabezados de respuesta se pueden generar rápidamente, pero los datos son los que afectarán a la medida más importante de todas: la rapidez con que el usuario verá la página.
En Cloudflare hacemos un amplio uso de NGINX. Al investigar el TTFB encontramos una diferencia significativa en TTFB de NGINX según se utilice compresión o no. La compresión gzip de las páginas web reduce en gran medida el tiempo que tarda una página web en descargarse, pero la compresión en sí tiene un coste. Ese coste hace que el TTFB aumente a pesar de que la descarga completa es más rápida.
Para ilustrarlo, tomamos la mayor página de Wikipedia (List of Advanced Dungeons and Dragons 2nd Edition Monsters) y la alojamos usando NGINX, con y sin compresión gzip habilitada. La tabla a continuación muestra el TTFB y el tiempo de descarga total con la compresión activada y desactivada.
| TTFB | Page loadedSe nota cómo con la compresión gzip activada, la página se descargó cinco veces más rápido, pero el TTFB era ocho veces mayor. Eso se debe a que NGINX espera hasta que la compresión haya comenzado antes de enviar los encabezados de HTTP. Cuando la compresión se desactiva, envía los encabezados de inmediato. Así que si nos fijamos en TTFB, parece como si la compresión fuera una mala idea. Pero si se comprueba el tiempo de descarga, se ve lo contrario.
Desde el punto de vista del usuario final, el TTFB es casi inútil. En este ejemplo real, de hecho se correlaciona negativamente con el tiempo de descarga: cuanto peor es el TTFB, mejor es el tiempo de descarga. Mirando el código fuente de NGINX nos dimos cuenta de que podríamos engañar y enviar rápidamente los encabezados para que pareciera que nuestro TTFB era estupendo incluso con compresión, pero al final decidimos no hacerlo: eso también habría afectado negativamente a la experiencia de usuario final, porque habríamos desperdiciado un valioso paquete cuando TCP se inicia con lentitud. Habría provocado que Cloudflare quedara bien en algunas pruebas, pero realmente habría perjudicado al usuario final.
Probablemente, el TTFB solo sea útil como tendencia. Y se mide mejor en el propio servidor para que se elimine la latencia de la red. Examinando una tendencia es posible detectar si existe un problema en el servidor web (por ejemplo, que se sobrecargue).
La medición remota del TTFB implica también medir la latencia de la red al mismo tiempo, lo que oculta qué mide realmente el TTFB: la rapidez con la que el servidor web es capaz de responder a una solicitud.
En Cloudflare, el TTFB no es una medida significativa. Nos interesa optimizar la experiencia de los usuarios finales y eso implica el tiempo real en que la página es visible para el usuario final. Iremos sacando herramientas para controlar específicamente la experiencia del usuario final, para que nuestros editores puedan ver y medir la experiencia de sus visitantes.
Etiquetado con Velocidad, Rendimiento