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

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:
- Espera + Redirección (o duración de espera)
- Worker + Caché (o duración de caché)
- DNS (o duración de DNS)
- Conexión (o duración de conexión)
- Solicitud (o duración de solicitud)
¿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.
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:
Table of Contents!
- Reducir la duración de espera del Time to First Byte
- ¿Cómo aumentan las redirecciones el Time to First Byte?
- Impacto en la Experiencia de Usuario (y SEO)
- Cómo medir problemas de TTFB causados por redirecciones
- Cómo auditar su sitio en busca de redirecciones
- Cómo minimizar el impacto de las redirecciones
- Lecturas adicionales: Guías de optimización
- Subpartes de TTFB: Artículos en profundidad
¿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.

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:
- 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.
- 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.
- 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.
- 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:
- 103 Early Hints: reduzca el TTFB percibido enviando pistas de recursos mientras el servidor procesa la respuesta completa.
- Configurar Cloudflare para Rendimiento: optimice su configuración de CDN para reducir cadenas de redirección y mejorar el TTFB global.
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:
- Arreglar e Identificar problemas de TTFB: el punto de partida de diagnóstico para toda optimización de TTFB.
- Duración de Caché: rendimiento del service worker, búsquedas en caché del navegador y bfcache.
- Duración de DNS: selección de proveedor DNS, configuración TTL y dns-prefetch.
- Duración de Conexión: handshake TCP, optimización TLS, HTTP/3 y preconnect.
Performance degrades unless you guard it.
I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.
Start the Engagement
