Solucionar e identificar problemas de Time to First Byte (TTFB)

Encontrar y solucionar problemas de Time to First Byte (TTFB)

Este artículo es parte de nuestra guía de Time to First Byte (TTFB). TTFB es una métrica de diagnóstico que mide el tiempo entre que un usuario solicita una página y el navegador recibe el primer byte de la respuesta. Aunque el TTFB no es un Core Web Vital en sí mismo, influye directamente tanto en el First Contentful Paint (FCP) como en el Largest Contentful Paint (LCP). Un buen TTFB es inferior a 800 milisegundos en el percentil 75.

En nuestro artículo anterior hablamos sobre el Time to First Byte. Si desea leer sobre los conceptos básicos, ese es un gran lugar para comenzar.

En este artículo nos centraremos en identificar los diferentes problemas de Time to First Byte y luego explicaremos cómo solucionarlos.

Consejo de TTFB: la mayoría de las veces el TTFB será mucho peor para los visitantes primerizos ya que no tienen una caché DNS para su sitio. Al rastrear el TTFB tiene mucho sentido distinguir entre visitantes primerizos y recurrentes.

Paso 1: Comprobar el TTFB en Search Console

"El primer paso para la recuperación es admitir que tienes un problema". Así que antes de hacer nada para arreglar el Time to First Byte, asegurémonos de que realmente tenemos un problema con el TTFB.

Desafortunadamente, el Time to First Byte no se reporta en Google Search Console, por lo que necesitamos recurrir a pagespeed.web.dev para consultar los datos CrUX de nuestro sitio. Afortunadamente, los pasos son sencillos: navegue a pagespeed.web.dev, introduzca la URL de su página y asegúrese de que el botón "origin" esté marcado (ya que necesitamos datos de todo el sitio y no solo de la página de inicio). Ahora cambie entre Móvil y Escritorio y compruebe el Time to First Byte para ambos tipos de dispositivo.

En el ejemplo a continuación verá un sitio que no cumple con los Core Web Vitals debido a un TTFB alto.

Paso 1b: Usar el encabezado Server-Timing para una visión más profunda

El encabezado de respuesta HTTP Server-Timing permite a su servidor comunicar métricas de rendimiento del backend directamente al navegador. Esto hace posible identificar exactamente qué parte del procesamiento del servidor es lenta sin necesidad de acceder a los registros del servidor.

Un encabezado Server-Timing típico se ve así:

Server-Timing: db;dur=53, app;dur=120, cache;desc="miss"

En este ejemplo el servidor informa tres valores de tiempo:

• db;dur=53: la consulta a la base de datos tomó 53 milisegundos.
• app;dur=120: la lógica de la aplicación (renderizado de plantillas, llamadas a API, etc.) tomó 120 milisegundos.
• cache;desc="miss": la caché del servidor no se utilizó para esta solicitud (un fallo de caché).

Puede leer estos valores en Chrome DevTools abriendo la pestaña Network, seleccionando la solicitud del documento y desplazándose a la sección "Server Timing" en la pestaña Timing. Los valores también son accesibles a través de la API PerformanceServerTiming en JavaScript:

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

Si su servidor aún no envía encabezados Server-Timing, considere agregarlos. La mayoría de los marcos web simplifican esto. En PHP puede agregar el encabezado antes de cualquier salida:

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

En Node.js con Express:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

El encabezado Server-Timing es especialmente útil cuando se combina con Real User Monitoring porque le permite correlacionar el rendimiento del lado del servidor con el TTFB que experimentan los usuarios reales. Aprenda más sobre cómo 103 Early Hints puede reducir aún más el TTFB percibido enviando sugerencias de recursos antes de que la respuesta completa esté lista.

Paso 2: Configurar el seguimiento RUM

El Time to First Byte es una métrica complicada. No podemos confiar simplemente en pruebas sintéticas para medir el TTFB porque en la vida real otros factores contribuirán a las fluctuaciones en el TTFB. Para obtener respuestas a todas las preguntas anteriores necesitamos medir los datos en la vida real y registrar cualquiera de los problemas que puedan ocurrir con el Time to First Byte. Esto se llama Real User Monitoring (RUM), y hay varias formas de habilitar el seguimiento RUM. Hemos desarrollado CoreDash justo para estos casos de uso. CoreDash es una herramienta RUM de bajo costo, rápida y efectiva que hace el trabajo. Por supuesto, hay muchas soluciones RUM y también harán el trabajo (aunque a un precio más alto).

Cómo pensar en el TTFB: Imagine que un servidor web es la cocina de un restaurante, y un usuario que solicita una página web es un cliente hambriento haciendo un pedido. Time to First Byte (TTFB) es el lapso de tiempo entre que el cliente hace su pedido y la cocina comienza a preparar la comida.
Así que el TTFB NO trata de qué tan rápido se cocina toda la comida (First Contentful Paint) y se sirve (Largest Contentful Paint), sino más bien qué tan receptiva es la cocina a la solicitud inicial.
El seguimiento RUM se compara con encuestar a los clientes para entender su experiencia gastronómica. Podría encontrar que los clientes sentados más lejos de la cocina reciben menos atención del camarero y son atendidos más tarde, o que los clientes habituales reciben un trato preferencial mientras que los nuevos visitantes tienen que esperar más por una mesa.

Paso 2b: Establecer una línea base de rendimiento

Antes de realizar cualquier cambio, establezca una línea base para su TTFB. Registre el TTFB del percentil 75 en las siguientes dimensiones, ya que esto le ayudará a medir la efectividad de sus optimizaciones más tarde:

1. TTFB general (móvil y escritorio por separado): capture el percentil 75 para cada tipo de dispositivo.
2. Top 10 páginas por tráfico: registre el TTFB para sus páginas de mayor tráfico individualmente.
3. Visitantes nuevos vs. visitantes recurrentes: los visitantes primerizos suelen tener un TTFB más alto debido a la sobrecarga de DNS y conexión.
4. Top 5 países por tráfico: la distancia geográfica a su servidor afecta significativamente al TTFB.
5. Desglose de subpartes de TTFB: registre el percentil 75 para cada subparte (espera, caché, DNS, conexión, solicitud).

Documente estos números en una hoja de cálculo. Después de implementar cada optimización, espere al menos 7 días para recopilar suficientes datos RUM antes de comparar los resultados. Un buen enfoque es abordar una subparte de TTFB a la vez, medir y luego pasar a la siguiente.

Paso 3: Identificar problemas de Time to First Byte

Aunque el Chrome User Experience Report (CrUX) de Google proporciona datos de campo valiosos, no ofrece detalles específicos sobre las causas de un TTFB alto. Para mejorar efectivamente el TTFB necesitamos saber exactamente qué está pasando a un nivel más detallado. En este punto tiene sentido distinguir entre TTFB que falla en general y TTFB que falla bajo condiciones específicas (aunque en realidad siempre habrá una mezcla).

3.1 El TTFB falla en general

1. Comprobar tiempos de "request" (solicitud) deficientes en general: Tiempos de solicitud deficientes significan que el "problema" está en el tiempo que le toma al servidor generar la página. Esta es la causa más común de puntuaciones TTFB deficientes.
2. Comprobar otras subpartes deficientes de TTFB: El TTFB no es solo una métrica única, sino que se puede desglosar en múltiples partes que tienen su propio potencial de optimización. Si la duración de espera, la duración de caché, la duración de búsqueda DNS o la duración de conexión son lentas, probablemente necesite ajustar la configuración de su servidor o comenzar a buscar un alojamiento de mejor calidad.

3.2 El TTFB falla bajo condiciones específicas

1. Segmentación por país: Entender la distribución geográfica de un TTFB alto es importante, especialmente para sitios web con una audiencia global. Si sirve sus páginas desde un servidor en un solo país (sin caché en el borde CDN), la distancia física entre la ubicación del usuario y el servidor que aloja el sitio web causará todo tipo de retrasos e impactará el TTFB. Considere configurar Cloudflare u otro CDN para acercar su contenido a los usuarios en todo el mundo.
   
2. Segmentación de caché: El almacenamiento en caché puede reducir el TTFB omitiendo la generación del HTML en el lado del servidor. Desafortunadamente, es común que el almacenamiento en caché esté deshabilitado o se omita por muchas razones. Por ejemplo, el almacenamiento en caché puede estar deshabilitado para usuarios conectados, páginas de carrito de compras, páginas con cadenas de consulta (por ejemplo, de Google Ads), páginas de resultados de búsqueda y páginas de pago. Si su sitio web utiliza almacenamiento en caché (en el borde), utilice el seguimiento RUM para comprobar la tasa de aciertos de caché.
   
3. Segmentación de página (clúster): La diferencia en el rendimiento del Time to First Byte (o la falta de diferencia) entre páginas o tipos de páginas es otra cosa que necesitamos determinar. Saber qué páginas fallan en la métrica TTFB dará información valiosa sobre cómo mejorar el Time to First Byte.
   
4. Segmentación de redirección: El tiempo de redirección se agrega directamente al TTFB. Cada redirección agrega tiempo extra antes de que el servidor web pueda comenzar a cargar la página. Medir y eliminar redirecciones innecesarias puede ayudar a mejorar el TTFB. Para una mirada más profunda a la optimización de redirecciones, consulte nuestra guía sobre la subparte de duración de espera del TTFB.
   
5. Otra segmentación: Si bien segmentar por las variables anteriores cubre a los sospechosos habituales, cada sitio es único y tiene sus propios desafíos. Afortunadamente, el seguimiento RUM está diseñado para permitir la segmentación por muchas más variables como RAM del dispositivo, velocidad de red, tipo de dispositivo, sistema operativo, variables personalizadas y mucho más.

Paso 4: Acercar los problemas y solucionar

Las subpartes del Time to First Byte (TTFB) son:

• Waiting + Redirect (o duración de espera)
• Worker + Cache (o duración de caché)
• DNS (o duración de DNS)
• Connection (o duración de conexión)
• Request (o duración de solicitud)

Paso 5: Lista de verificación de arreglos rápidos para problemas comunes de TTFB

Basado en la subparte que más contribuye a su TTFB, aquí hay una referencia rápida para las correcciones más comunes:

Medir TTFB con JavaScript

Puede medir el TTFB completo y sus subpartes directamente en el navegador utilizando la API Navigation Timing. El siguiente fragmento calcula el TTFB y registra cada subparte:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

Este código proporciona el mismo desglose que herramientas como CoreDash muestran en el panel de atribución de TTFB. Ejecutar este fragmento en la consola del navegador le da una lectura inmediata para una sola carga de página, mientras que las herramientas RUM recopilan estos datos a través de miles de usuarios reales para producir valores confiables del percentil 75.

Lectura adicional: Guías de optimización

Para técnicas de optimización específicas que mejoren el TTFB, explore estas guías relacionadas:

• 103 Early Hints: envíe sugerencias de recursos antes de que la respuesta completa esté lista, permitiendo que el navegador comience a cargar recursos críticos mientras el servidor aún está procesando.
• Configurar Cloudflare para rendimiento: configure el CDN, el almacenamiento en caché y las funciones de borde de Cloudflare para reducir el TTFB para audiencias globales.

Subpartes de TTFB: Artículos detallados

Cada subparte del Time to First Byte tiene estrategias de optimización únicas. Explore el área específica que sus datos RUM identifican como el cuello de botella:

• Duración de espera: redirecciones, cola del navegador y optimización HSTS.
• Duración de caché: rendimiento del service worker, caché del navegador y bfcache.
• Duración de DNS: selección del proveedor de DNS, configuración TTL y dns-prefetch.
• Duración de conexión: protocolo de enlace TCP, optimización TLS, HTTP/3 y preconnect.