Transloadit

¿Qué es el tiempo hasta el primer byte?

El tiempo hasta el primer byte (TTFB) es el tiempo transcurrido desde el inicio de una solicitud o navegación hasta que llega el primer byte de la respuesta. Según dónde comience la medición, puede incluir la redirección, la resolución DNS, el establecimiento de la conexión y de TLS, además del procesamiento del servidor.

Cómo funciona el tiempo hasta el primer byte

El TTFB marca el momento en que empieza a llegar una respuesta, por lo que todo lo anterior a ese momento cuenta y nada de lo posterior cuenta. Para una navegación de página medida en el navegador, web.dev enumera las fases que suma: tiempo de redirección, inicio del trabajador de servicio, resolución DNS, conexión y negociación TLS, y la solicitud hasta el primer byte de la respuesta. Los navegadores exponen ese momento como responseStart en las API Navigation Timing y Resource Timing. Un acierto de caché en una CDN elimina del total el viaje al origen, por lo que una misma URL puede mostrar valores muy distintos en un fallo de caché y en un acierto de caché. Cuando hay una CDN en la ruta, un encabezado de respuesta Server-Timing puede desglosar aún más la cifra: Amazon CloudFront, por ejemplo, puede informar si una respuesta fue un acierto o un fallo de caché y, en caso de fallo, indicar la latencia hasta el primer byte del origen por separado de la suya. Los servidores y los intermediarios eligen qué métricas Server-Timing enviar, así que el encabezado solo muestra lo que informan. En la entrega multimedia, el TTFB permite ubicar la demora anterior al inicio de la transferencia de una lista de reproducción, un segmento, una imagen o una respuesta de API; no indica cuánto tarda después en descargarse el cuerpo.

Datos clave

  1. ¿Por qué dos herramientas informan valores de TTFB distintos para la misma solicitud? Empiezan a medir en puntos diferentes. La biblioteca web-vitals mide una navegación desde su inicio, o desde la activación en el caso de una página prerenderizada, hasta responseStart, lo que incluye redirecciones, DNS, conexión y TLS. Chrome DevTools denomina «Waiting (TTFB)» a una fase más acotada: sigue a las fases separadas de resolución DNS, conexión y envío de la solicitud, y abarca la latencia de un viaje de ida y vuelta más el tiempo que tardó el servidor en preparar la respuesta. El time_starttransfer de curl se mide desde el inicio de la transferencia e incluye la resolución de nombres, el establecimiento de la conexión y la negociación TLS. Un registro de CDN es aún más acotado: el campo time-to-first-byte de CloudFront se mide en el servidor, desde la recepción de la solicitud hasta la escritura del primer byte de la respuesta, por lo que no incluye tiempo de red del cliente. Asegúrate de que las definiciones coincidan antes de comparar cifras o establecer un objetivo.
  2. ¿Existe un valor objetivo? Para las navegaciones de páginas, web.dev ofrece una orientación aproximada: 0,8 segundos o menos es bueno, y más de 1,8 segundos es malo. El TTFB no es una Core Web Vital, y web.dev presenta los umbrales como una orientación aproximada porque una página renderizada en el servidor puede tener un TTFB mayor y aun así mostrar su contenido antes que una página que se renderiza en el navegador. La orientación se aplica a solicitudes de navegación, es decir, documentos HTML; web.dev no establece ningún umbral para imágenes, segmentos de video ni llamadas a API.
  3. ¿Se puede medir el TTFB en condiciones reales para contenido multimedia servido desde el nombre de host de una CDN? Solo si la CDN lo permite enviando un encabezado de respuesta Timing-Allow-Origin que incluya el origen de la página o el comodín *. Para un recurso de otro origen enviado sin ese encabezado, la API Resource Timing informa responseStart como 0, al igual que las marcas de tiempo de DNS, conexión y solicitud. responseStart también es 0 para un recurso recuperado al instante de una caché, así que excluye los ceros en lugar de incluirlos en el promedio. El mismo encabezado controla si una página puede leer métricas Server-Timing de otro origen.
  4. ¿Una respuesta 103 Early Hints cuenta como el primer byte? En las API de los navegadores, sí: responseStart devuelve el momento de la primera respuesta provisional cuando la hay, y web.dev indica que la 103 cuenta como los primeros bytes. En cambio, finalResponseHeadersStart indica el inicio de la respuesta final. Chrome informó la respuesta final como responseStart a partir de la versión 115 y revirtió ese cambio en la versión 133, por lo que los datos de TTFB de Chrome pueden variar entre esas versiones para los sitios que envían Early Hints. Enviar los encabezados de respuesta de forma anticipada tiene un efecto similar, así que un TTFB menor tras habilitar cualquiera de esas dos opciones no demuestra, por sí solo, que el contenido principal llegue antes.

Cuándo importa el tiempo hasta el primer byte

Compara el TTFB de un fallo y un acierto de caché de una CDN para la misma URL, en condiciones similares en los demás aspectos, para ver cuánta latencia añade la ruta del fallo a la ruta de entrega. Un TTFB bajo no garantiza una respuesta completa rápida, porque el tiempo de descarga y el de renderizado siguen siendo independientes.

Cómo ayuda Transloadit con el tiempo hasta el primer byte

En Smart CDN de Transloadit, un fallo de caché realiza un trabajo de procesamiento que un acierto de caché omite. En caso de fallo, la solicitud importa el original desde tu almacenamiento y ejecuta tu Template para producir el resultado; en caso de acierto, el resultado almacenado en caché se entrega desde el borde de la red sin ejecutar nada. La página del producto Smart CDN informa por separado los tiempos de las solicitudes con caché fría y caliente, y aconseja tener en cuenta el tiempo de recuperación del origen y de transformación cuando la caché está fría.

La página del producto no indica si sus tiempos corresponden al tiempo hasta el primer byte o al tiempo de respuesta completo, ni si se envían bytes de respuesta antes de que termine el procesamiento en un fallo de caché, y los presenta como mediciones fechadas que varían según la carga de trabajo. Mide tu propio Template comparando un fallo de caché con un acierto de caché para la misma URL. Una primera solicitud y otra repetida no constituyen automáticamente ese par: la URL puede estar ya almacenada en la caché del borde de la red, y el Robot /file/serve indica a los navegadores que almacenen los resultados en caché de forma predeterminada, por lo que una solicitud repetida desde un navegador puede responderse localmente. La página del producto aconseja revisar los encabezados de caché de las respuestas al depurar.

Explora las capacidades de entrega de Transloadit

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional

Conecta las subidas, el procesamiento, la IA, el almacenamiento y la entrega mediante una sola API declarativa, mientras nos encargamos por ti del stack de encoding, el escalado y los cambios constantes de formatos.

Prueba Transloadit gratis