Tiempo hasta el primer byte (TTFB)

Jeremy Wagner
Jeremy Wagner
GitHub LinkedIn
Barry Pollard

Browser Support

  • Chrome: 43.
  • Edge: 12.
  • Firefox: 35.
  • Safari: 11.

Source

¿Qué es el TTFB?

El TTFB es una métrica que mide el tiempo entre la solicitud de un recurso y el momento en que comienza a llegar el primer byte de una respuesta.

Una visualización de los tiempos de solicitud de red. Los tiempos de ejecución de izquierda a derecha son redireccionamiento, inicio del trabajador de servicio, evento de recuperación del trabajador de servicio, caché HTTP, DNS, TCP, solicitud, sugerencias anticipadas (103), respuesta (que se superpone con la solicitud de descarga), procesamiento y carga. Los tiempos asociados son redirectStart y redirectEnd, fetchStart, domainLookupStart, domainLookupEnd, connectStart, secureConnectionStart, connectEnd, requestStart, interimResponseStart, responseStart, unloadEventStart, unloadEventEnd, responseEnd, domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, domComplete, loadEventStart y loadEventEnd.
Un diagrama de las fases de solicitud de red y sus tiempos asociados. El TTFB mide el tiempo transcurrido entre startTime y responseStart.

El TTFB es la suma de las siguientes fases de solicitud:

  • Tiempo de redireccionamiento
  • Tiempo de inicio del service worker (si corresponde)
  • búsqueda de DNS
  • Negociación de conexión y TLS
  • Solicitud, hasta el punto en el que llegó el primer byte de la respuesta

Reducir la latencia en el tiempo de configuración de la conexión y en el backend puede disminuir el TTFB.

Otras definiciones de TTFB

La definición anterior es la definición convencional, pero con la introducción de las sugerencias anticipadas, lo que se considera el "primer byte" está en debate. firstInterimResponseStart es una nueva entrada de tiempo adicional a responseStart para diferenciar entre estos, pero solo es compatible con Chrome y navegadores basados en Chromium. Por lo tanto, algunos navegadores y herramientas (incluida CrUX) miden hasta que se reciben los primeros bytes, incluidos los indicadores anticipados.

Las sugerencias anticipadas son solo un ejemplo más reciente de la respuesta anticipada. Algunos servidores permiten que se borre la respuesta del documento antes de que el cuerpo principal esté disponible, ya sea solo con los encabezados HTTP o con el elemento <head>, que podrían considerarse similares en efecto a los indicadores anticipados y, por lo tanto, también enturbian la definición de lo que mide el TTFB.

Como medida de cuándo el navegador recibe los "primeros bytes" de datos prácticos para el documento, todas estas definiciones se pueden considerar válidas. Enviar datos con anticipación tiene un valor real si la respuesta completa llevará un poco más de tiempo. Lo más importante es comprender qué mide la herramienta que usas y cómo se ve afectada por la plataforma que se mide. Esto dificulta la comparación del TTFB entre diferentes plataformas o tecnologías, según las funciones que usen y cómo eso afecte la medición del TTFB que se use.

El TTFB también se suele considerar un indicador del tiempo de respuesta del servidor o del host. Sin embargo, se verá afectado por factores fuera de ese control directo, como el tiempo de redireccionamiento, ya sea que se publique desde un acierto de caché de una CDN o tenga que realizar un recorrido potencialmente más largo de regreso a un servidor de origen. Esto es particularmente evidente en los datos de campo. Por lo general, las pruebas de lab se ven menos afectadas por estos factores, ya que la URL de destino suele probarse y, a menudo, se niegan los cambios de almacenamiento en caché de forma repetida. Lighthouse informa el tiempo de respuesta del servidor en lugar del TTFB para que esto sea más claro, pero es posible que otras herramientas de Lab no lo hagan.

¿Qué es un buen nivel de TTFB?

Debido a que el TTFB precede a las métricas centradas en el usuario, como el primer procesamiento de imagen con contenido (FCP) y el procesamiento de imagen con contenido más grande (LCP), se recomienda que tu servidor responda a las solicitudes de navegación con la suficiente rapidez para que el percentil 75 de los usuarios experimente un FCP dentro del umbral "bueno". Como guía aproximada, la mayoría de los sitios deben esforzarse por tener un TTFB de 0.8 segundos o menos.

Los valores buenos de TTFB son de 0.8 segundos o menos, los valores deficientes son superiores a 1.8 segundos y los valores intermedios deben mejorarse.
Los valores buenos de TTFB son de 0.8 segundos o menos, y los valores deficientes son superiores a 1.8 segundos.

Cómo medir el TTFB

El TTFB se puede medir en el laboratorio o en el campo de las siguientes maneras.

Herramientas de campo

Herramientas de lab

Mide el TTFB en JavaScript

Puedes medir el TTFB de las solicitudes de navegación en el navegador con la API de Navigation Timing. En el siguiente ejemplo, se muestra cómo crear un PerformanceObserver que detecte una entrada navigation y la registre en la consola:

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

La biblioteca de JavaScript web-vitals también puede medir el TTFB en el navegador de forma más concisa:

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

Mide las solicitudes de recursos

El TTFB se aplica a todas las solicitudes, no solo a las de navegación. En particular, los recursos alojados en servidores de origen cruzado pueden generar latencia debido a la necesidad de configurar conexiones a esos servidores. Para medir el TTFB de los recursos en el campo, usa la API de Resource Timing dentro de un PerformanceObserver:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

El fragmento de código anterior es similar al que se usa para medir el TTFB de una solicitud de navegación, excepto que, en lugar de consultar entradas de 'navigation', consultas entradas de 'resource'. También se considera el hecho de que algunos recursos cargados desde el origen principal pueden mostrar un valor de 0, ya que la conexión ya está abierta o un recurso se recupera instantáneamente desde una caché.

Cómo mejorar el TTFB

Si deseas obtener orientación para mejorar el TTFB de tu sitio, consulta nuestra guía detallada para optimizar el TTFB.