Reducir la subparte de duración de espera del Time to First Byte

La duración de espera consiste en redirecciones y la cola del navegador. Aprenda a auditar redirecciones, configurar HSTS y eliminar cadenas de redirección para reducir el TTFB

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-21

Reducir la duración de espera del Time to First Byte

Este artículo es parte de nuestra guía sobre Time to First Byte (TTFB). La duración de espera es la primera subparte del TTFB y consiste principalmente en el tiempo de redirección y la cola del navegador. Una duración de espera alta casi siempre es causada por redirecciones innecesarias que añaden viajes de ida y vuelta antes de que el servidor pueda comenzar a procesar la solicitud real.

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

¿Busca optimizar el Time to First Byte? Este artículo proporciona un análisis en profundidad de la parte de duración de espera del Time to First Byte. Si busca comprender o arreglar el Time to First Byte y no sabe qué significa la duración de espera, por favor lea qué es el Time to First Byte y arreglar e identificar problemas de Time to First Byte antes de comenzar con este artículo.

La parte waitingDuration del Time to First Byte consiste en el tiempo donde el navegador podría estar realizando otras tareas antes de comenzar a conectarse a un servidor web, más cualquier tiempo de redirección. Cuando los datos de Real User Monitoring (RUM) muestran una waitingDuration alta, puede estar bastante seguro de que el culpable es el tiempo de redirección.

Las redirecciones pueden tener un gran impacto en el Time to First Byte (TTFB) porque cada redirección se suma al tiempo que le toma a un navegador 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 se incluyen típicamente en la medición completa de TTFB (ver cuadro azul). Esto significa que el tiempo tomado para todas las redirecciones se factoriza en la puntuación general de TTFB, haciéndola parecer potencialmente más alta 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 le ayuda a priorizar qué redirecciones eliminar primero:

Tipo de redirección Estado HTTP Caso de uso Impacto en TTFB
Redirección permanente 301 La página se ha movido permanentemente a una nueva URL Los navegadores pueden almacenar en caché, reduciendo el impacto repetido
Redirección temporal 302 La página está temporalmente en una URL diferente No almacenado en caché por los navegadores; viaje de ida y vuelta completo cada vez
Redirección temporal (explícita) 307 Igual que 302 pero preserva el método HTTP No almacenado en caché; mismo impacto que 302
Redirección permanente (explícita) 308 Igual que 301 pero preserva el método HTTP Los navegadores pueden almacenar en caché, similar a 301

Una sola redirección típicamente añade de 50 a 300 milisegundos al TTFB dependiendo de las condiciones de la red y el tiempo de respuesta del servidor. Cuando dos o tres redirecciones se encadenan, esos tiempos se acumulan y pueden empujar el TTFB muy por encima del umbral "bueno" de 800ms.

Aumento del tiempo de procesamiento del servidor

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

Cadenas de redirección

En algunos casos, pueden ocurrir múltiples redirecciones antes de llegar al destino final. Esto crea una "cadena de redirección" que puede aumentar significativamente el TTFB. Cada redirección en la cadena añade su propio tiempo de procesamiento, sumándose al retraso antes de que se reciba el primer byte de contenido real.

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

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

En este ejemplo, ocurren tres redirecciones antes de que el navegador reciba algún contenido. La primera redirección (HTTP a HTTPS) puede eliminarse con HSTS. La segunda y tercera redirecciones pueden eliminarse 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 de red adicionales entre el cliente y el servidor. Esto introduce latencia de red extra, especialmente si las redirecciones involucran diferentes dominios o servidores. La distancia física entre el cliente y el servidor para cada redirección puede impactar aún más el TTFB.

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

Se podría pensar que las redirecciones JavaScript deberían preferirse ya que no añaden al Time to First Byte. Desafortunadamente, las redirecciones 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 SEO)

Aunque las redirecciones a veces son 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 la renderización inicial de la página, frustrando potencialmente a los usuarios.
  • SEO: Aunque el TTFB no es un factor de clasificación directo, influye en otras métricas como Largest Contentful Paint (LCP), que es un Core Web Vital considerado por los motores de búsqueda.
  • Presupuesto de rastreo (Crawl budget): Los rastreadores de motores de búsqueda siguen las redirecciones, lo que significa que cada redirección consume presupuesto de rastreo adicional. Para sitios web grandes, esto puede ralentizar el descubrimiento de contenido nuevo o actualizado.

Cómo medir problemas de TTFB causados por redirecciones

Para encontrar el impacto que experimentan los usuarios reales causado por las redirecciones, necesitará usar una herramienta RUM como CoreDash. Real User Monitoring le permitirá rastrear los Core Web Vitals con gran detalle.

En CoreDash, simplemente haga clic en "redirect count" para visualizar sus datos segmentados por conteo de redirecciones. Luego, por ejemplo, haga clic en el segmento "1 redirect" para filtrar los datos RUM por "1 redirect" y ver todas las URLs afectadas.

ttfb coredash redirect count 3

Cómo auditar su sitio en busca de redirecciones

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

Paso 1: Rastrear su sitio

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

Paso 2: Identificar cadenas de redirección

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

Paso 3: Arreglar y verificar

Actualice sus enlaces internos para que apunten directamente a la URL de destino final. Después de actualizar los enlaces, vuelva a rastrear para verificar que las redirecciones ya no se activan desde la navegación interna. Use 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('Redirect detected!', {
      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, siga estos 3 simples pasos para evitar problemas de redirección:

  • Minimice el uso de redirecciones donde sea posible.
  • Evite cadenas de redirección actualizando los enlaces para que apunten directamente a la URL de destino final.
  • Use 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. Las redirecciones del mismo origen se originan en enlaces en su propio sitio web. Debería tener control total sobre estos enlaces y debería priorizar arreglar estos enlaces cuando trabaje en el Time to First Byte. El método típico para encontrar estas redirecciones internas es usando cualquiera de las herramientas disponibles que le permitirán verificar todo su sitio web en busca de redirecciones.

Redirecciones de origen cruzado. Las redirecciones de origen cruzado se originan en enlaces en otros sitios web. Tiene muy poco control sobre estos. Para enlaces de alto impacto que generan mucho tráfico, considere contactar al webmaster del sitio para actualizar la URL enlazada.

Cadenas de redirección. Las 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 ponen más presión en el Time to First Byte y deben evitarse a toda costa. Nuevamente, use una herramienta para encontrar estos tipos de redirecciones y arreglarlos.

Redirecciones HTTP a HTTPS y HSTS

Las redirecciones HTTP a HTTPS son uno de los tipos de redirección más comunes. Cada visitante que escribe su dominio sin "https://" o sigue un enlace HTTP antiguo experimentará una redirección 301. El encabezado Strict-Transport-Security (HSTS) elimina esta redirección para los visitantes recurrentes diciéndole al navegador que siempre use HTTPS.

Para habilitar HSTS, añada el siguiente encabezado a la respuesta de su servidor:

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

Aquí está lo que 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 su dominio sea incluido en la lista de precarga HSTS integrada en el navegador, lo que significa que incluso la primera visita usará HTTPS sin una redirección.

Para enviar su dominio a la lista de precarga HSTS, visite hstspreload.org. Una vez que su dominio esté en la lista de precarga, los navegadores nunca harán una solicitud HTTP a su dominio, eliminando completamente la redirección HTTP a HTTPS para todos los visitantes.

En Apache, puede 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. Verificar y actualizar regularmente sus enlaces internos. Siempre que cambie la ubicación de una página, actualice sus enlaces internos a esa página para asegurar que no queden referencias a la ubicación anterior de la página.
  2. Manejar 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, podrían no actualizarse en los motores de búsqueda.
  3. Usar URLs relativas: al enlazar a páginas en su propio sitio web, use URLs relativas en lugar de URLs absolutas. Esto ayudará a prevenir redirecciones innecesarias.
  4. Usar URLs canónicas: si tiene múltiples páginas con contenido similar, use una URL canónica para indicar la versión preferida de la página. Esto ayudará a prevenir contenido duplicado y redirecciones innecesarias.

Lecturas adicionales: Guías de optimización

Para técnicas de optimización relacionadas, explore estas guías:

Subpartes de TTFB: Artículos en profundidad

La duración de espera es una de las cinco subpartes del TTFB. Explore las otras subpartes para comprender el panorama completo:

Ask AI why your INP spiked.

CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.

See How It Works
Reducir la subparte de duración de espera del Time to First ByteCore Web Vitals Reducir la subparte de duración de espera del Time to First Byte