Reducir la subparte de Tiempo de Espera (Waiting Duration) del Time to First Byte

Reducir el Tiempo de Espera del Time to First Byte

Este artículo forma parte de nuestra guía sobre el Time to First Byte (TTFB). El tiempo de espera (waiting duration) es la primera subparte del TTFB y se compone principalmente del tiempo de redirección y de la puesta en cola del navegador. Un tiempo de espera elevado casi siempre se debe a redirecciones innecesarias que añaden viajes de ida y vuelta (round trips) antes de que el servidor pueda empezar a procesar la solicitud real.

El Time to First Byte (TTFB) se puede desglosar en las siguientes subpartes:

• Espera + Redirección (o tiempo de espera, waiting duration)
• Worker + Caché (o duración de la caché)
• DNS (o duración de DNS)
• Conexión (o duración de la conexión)
• Solicitud (o duración de la solicitud)

¿Buscas optimizar el Time to First Byte? Este artículo cubre la parte del tiempo de espera del Time to First Byte. Si buscas entender o solucionar problemas de Time to First Byte y no sabes qué significa el tiempo de espera, por favor lee qué es el Time to First Byte y cómo identificar y solucionar problemas de Time to First Byte antes de empezar con este artículo.

Las redirecciones pueden tener un gran impacto en el Time to First Byte (TTFB) porque cada redirección se suma al tiempo que tarda un navegador en recibir el primer byte de datos de un servidor. Así es como las redirecciones influyen en el TTFB:

¿Cómo aumentan las redirecciones el Time to First Byte?

Las redirecciones suelen incluirse en la medición completa del TTFB (ver recuadro azul). Esto significa que el tiempo empleado en todas las redirecciones se tiene en cuenta en la puntuación global del TTFB, lo que potencialmente hace que parezca más alto de lo esperado.

Cuando una página es redirigida, estos son los pasos habituales que ocurren:

• El navegador envía una solicitud inicial a la URL original.
• El servidor procesa esta solicitud y responde con un código de estado de redirección (por ejemplo, 301 o 302).
• El navegador envía entonces una nueva solicitud a la URL redirigida.
• El servidor procesa esta segunda solicitud y comienza a enviar el contenido real.

Tipos de redirecciones y su impacto

No todas las redirecciones son iguales. Comprender los diferentes tipos te ayuda a priorizar qué redirecciones eliminar primero:

Una única redirección suele añadir entre 50 y 300 milisegundos al TTFB dependiendo de las condiciones de la red y del tiempo de respuesta del servidor. Cuando dos o tres redirecciones se encadenan, esos tiempos se suman y pueden elevar el TTFB muy por encima del umbral "bueno" de 800 ms.

Aumento del tiempo de procesamiento del servidor

Este procesamiento adicional aumenta el TTFB global, ya que cada paso requiere tiempo para que el servidor gestione la solicitud y responda.

Cadenas de redirección

En algunos casos, pueden producirse múltiples redirecciones antes de llegar al destino final. Esto crea una "cadena de redirección" que aumenta el TTFB. Cada redirección en la cadena suma su propio tiempo de procesamiento, incrementando el retraso antes de que se reciba el primer byte de contenido real.

Un ejemplo común de cadena de redirección:

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/es/

En este ejemplo, se producen tres redirecciones antes de que el navegador reciba cualquier contenido. La primera redirección (de HTTP a HTTPS) se puede eliminar con HSTS. La segunda y tercera redirecciones se pueden eliminar actualizando los enlaces internos para que apunten directamente a la URL final.

Latencia de red

Las redirecciones a menudo implican viajes de ida y vuelta adicionales en la red entre el cliente y el servidor. Esto introduce una latencia de red adicional, especialmente si las redirecciones involucran dominios o servidores diferentes. La distancia física entre el cliente y el servidor para cada redirección puede afectar aún más al TTFB.

Redirecciones JavaScript vs. Redirecciones del lado del servidor: Solo las redirecciones del lado del servidor (que funcionan con una cabecera de redirección 30x) se suman al Time to First Byte. Las redirecciones con JavaScript no se suman al Time to First Byte porque el servidor ya ha enviado una respuesta completa (200).

Se podría pensar que las redirecciones con JavaScript deberían ser preferidas ya que no se suman al Time to First Byte. Lamentablemente, las redirecciones con JavaScript son mucho más lentas para los usuarios reales y causarán una mala experiencia de usuario.

Impacto en la experiencia de usuario (y en el SEO)

Si bien las redirecciones son a veces necesarias, su impacto en el TTFB puede tener implicaciones más amplias:

• Experiencia de usuario: Un TTFB más lento debido a redirecciones puede retrasar el renderizado inicial de la página, lo que puede frustrar a los usuarios.
• SEO: Aunque el TTFB no es un factor de clasificación directo, influye en otras métricas como el Largest Contentful Paint (LCP), que es un Core Web Vital que los motores de búsqueda tienen en cuenta.
• Presupuesto de rastreo (Crawl budget): Los rastreadores de los motores de búsqueda siguen las redirecciones, lo que significa que cada redirección consume un presupuesto de rastreo adicional. Para los sitios web grandes, esto puede ralentizar el descubrimiento de contenido nuevo o actualizado.

Cómo medir los problemas de TTFB causados por redirecciones

Para conocer el impacto que sufren los usuarios reales debido a las redirecciones, necesitarás usar una herramienta RUM como CoreDash. La Monitorización de Usuarios Reales te permitirá hacer un seguimiento muy detallado de los Core Web Vitals.

En CoreDash, simplemente haz clic en "redirect count" (recuento de redirecciones) para visualizar tus datos segmentados por el número de redirecciones. Luego, por ejemplo, haz clic en el segmento "1 redirect" para filtrar los datos RUM por "1 redirección" y ver todas las URL afectadas.

Cómo auditar tu sitio en busca de redirecciones

Una auditoría sistemática de redirecciones implica tres pasos:

Paso 1: Rastrea tu sitio

Utiliza una herramienta de rastreo (como MarketingTracer, Screaming Frog o Sitebulb) para rastrear todo tu sitio web. El rastreador informará de todas las URL internas que respondan con un código de estado 3xx. Exporta la lista y ordénala por el número de enlaces internos entrantes que apuntan a cada URL redirigida.

Paso 2: Identifica las cadenas de redirección

Filtra los resultados del rastreo para encontrar cualquier URL que redirija a otra URL que también redirige. Estas cadenas deben arreglarse primero porque multiplican la penalización del TTFB.

Paso 3: Corrige y verifica

Actualiza tus enlaces internos para que apunten directamente a la URL de destino final. Después de actualizar los enlaces, vuelve a rastrear para verificar que las redirecciones ya no se activan desde la navegación interna. Usa el siguiente fragmento de JavaScript para detectar redirecciones desde el navegador:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  if (nav.redirectCount > 0) {
    console.warn('¡Redirección detectada!', {
      redirectCount: nav.redirectCount,
      redirectTime: nav.redirectEnd - nav.redirectStart,
      finalUrl: nav.name
    });
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Cómo minimizar el impacto de las redirecciones

Como regla general, sigue estos 3 sencillos pasos para evitar problemas de redirección:

• Minimiza el uso de redirecciones siempre que sea posible.
• Evita las cadenas de redirección actualizando los enlaces para que apunten directamente a la URL de destino final.
• Usa redirecciones del lado del servidor en lugar de redirecciones del lado del cliente cuando sea posible, ya que generalmente son más rápidas.

Redirecciones del mismo origen (Same origin). Las redirecciones del mismo origen provienen de enlaces de tu propio sitio web. Deberías tener un control total sobre estos enlaces y deberías priorizar su corrección cuando trabajes en el Time to First Byte. El método típico para encontrar estas redirecciones internas es mediante el uso de cualquiera de las herramientas disponibles que te permitirán comprobar las redirecciones de todo tu sitio web.

Redirecciones de origen cruzado (Cross-origin). Las redirecciones de origen cruzado provienen de enlaces en otros sitios web. Tienes muy poco control sobre estas. Para los enlaces de gran impacto que generan mucho tráfico, considera la posibilidad de contactar con el webmaster del sitio para actualizar la URL vinculada.

Cadenas de redirección. Múltiples redirecciones o cadenas de redirección ocurren cuando una sola redirección no redirige a la ubicación final del recurso. Estos tipos de redirecciones suponen una carga mayor para el Time to First Byte y deben evitarse a toda costa. Nuevamente, usa una herramienta para encontrar este tipo de redirecciones y corregirlas.

Redirecciones de HTTP a HTTPS y HSTS

Las redirecciones de HTTP a HTTPS son uno de los tipos de redirección más comunes. Todo visitante que escriba tu dominio sin "https://" o que siga un antiguo enlace HTTP experimentará una redirección 301. La cabecera Strict-Transport-Security (HSTS) elimina esta redirección para los visitantes recurrentes al decirle al navegador que use siempre HTTPS.

Para habilitar HSTS, añade la siguiente cabecera a la respuesta de tu servidor:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

A continuación, explicamos qué significa cada directiva:

• max-age=31536000: el navegador recordará usar HTTPS para este dominio durante un año (31.536.000 segundos).
• includeSubDomains: aplica el requisito de HTTPS a todos los subdominios también.
• preload: permite que tu dominio se incluya en la lista de precarga HSTS integrada del navegador, lo que significa que incluso la primera visita usará HTTPS sin redirección.

Para enviar tu dominio a la lista de precarga HSTS, visita hstspreload.org. Una vez que tu dominio esté en la lista de precarga, los navegadores nunca realizarán una solicitud HTTP a tu dominio, eliminando por completo la redirección de HTTP a HTTPS para todos los visitantes.

En Apache, puedes añadir HSTS con:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

En Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

En general, recomendamos:

1. Comprobar y actualizar periódicamente tus enlaces internos. Siempre que cambies la ubicación de una página, actualiza tus enlaces internos a esa página para asegurarte de que no queden referencias a la ubicación de la página anterior.
2. Manejar las redirecciones a nivel de servidor. El método de redirección preferido es una redirección 301. Una redirección 301 es una redirección permanente, mientras que una redirección 302 es una redirección temporal. Las redirecciones temporales, por ejemplo, pueden no actualizarse en los motores de búsqueda.
3. Usar URL relativas: al enlazar a páginas de tu propio sitio web, usa URL relativas en lugar de URL absolutas. Esto ayudará a evitar redirecciones innecesarias.
4. Usar URL canónicas: si tienes varias páginas con contenido similar, usa una URL canónica para indicar la versión preferida de la página. Esto ayudará a prevenir el contenido duplicado y las redirecciones innecesarias.

Lecturas adicionales: Guías de optimización

Guías relacionadas:

• 103 Early Hints: reduce el TTFB percibido enviando sugerencias de recursos mientras el servidor procesa la respuesta completa.
• Configurar Cloudflare para el rendimiento: optimiza la configuración de tu CDN para reducir las cadenas de redirección y mejorar el TTFB global.

Subpartes del TTFB: Guías completas

El tiempo de espera es una de las cinco subpartes del TTFB. Explora las otras subpartes para tener una visión completa:

• Identificar y solucionar problemas de TTFB: el punto de partida de diagnóstico para toda optimización del TTFB.
• Duración de la caché (Cache Duration): rendimiento de los service workers, búsquedas en la caché del navegador y bfcache.
• Duración de DNS (DNS Duration): selección del proveedor de DNS, configuración de TTL y dns-prefetch.
• Duración de la conexión (Connection Duration): handshake TCP, optimización TLS, HTTP/3 y preconnect.
• Duración de la solicitud (Request Duration): tiempo de procesamiento del servidor, consultas a bases de datos y optimización del backend.