miji.beEl rendimiento web es un indicador que influye tanto en la experiencia del usuario como en la posición en los buscadores, y el procesamiento de las redirecciones de las URLs cortas también afecta a esa velocidad. Cuanto más tarda en cargarse una página móvil, más personas pueden abandonarla. En un acceso a través de una URL corta, el navegador primero se conecta al servidor del servicio de URLs cortas, recibe la respuesta de redirección y después se conecta al servidor de destino, de modo que la comunicación se produce en 2 etapas. El tiempo hasta que se muestra la página se alarga en lo que dura esta comunicación de ida y vuelta adicional (round trip). Una solicitud de página que incluye una redirección tiene una latencia hasta la visualización más larga que una solicitud sin redirección, y la diferencia se nota más en entornos con conexiones lentas.
En una cadena de redirecciones, el proceso de conexión de cada salto (resolución DNS / conexión TCP / handshake TLS / respuesta HTTP) se va acumulando tal cual, y todo se vuelve más lento a medida que aumentan los saltos. Con una redirección de 1 salto (URL corta → URL final), se añade la comunicación de 1 conjunto de resolución DNS + conexión TCP + handshake TLS + respuesta HTTP. Con una redirección de 2 saltos (URL corta → URL intermedia → URL final), al tráfico de 2 conjuntos se suma el procesamiento de la redirección por parte del navegador. Con 3 saltos o más, las comunicaciones de ida y vuelta se acumulan según el número de saltos. Cuantos más saltos hay, mayor es también el peligro de que el enlace deje de funcionar por un fallo de un servidor intermedio o por un tiempo de espera agotado. Cuando se usan URLs cortas, mantener bajo el número total de saltos de la cadena de redirecciones facilita reducir los retrasos.
De las Core Web Vitals, las redirecciones influyen en particular en 2 indicadores: LCP (Largest Contentful Paint) e INP (Interaction to Next Paint). LCP es un indicador que mide el tiempo hasta que se muestra el contenido principal de la página, y Google define como "bueno" un valor de 2,5 segundos o menos. Según la explicación sobre LCP de web.dev (a octubre de 2026), el LCP incluye también el tiempo de las redirecciones. Es decir, si una redirección tarda 500 milisegundos, aunque la página de destino alcance el LCP en 2,0 segundos, el LCP que se percibe es de 2,5 segundos y se acerca al límite de "bueno". El efecto en INP es indirecto, y a veces influye en la respuesta a las operaciones que se hacen justo después de la redirección. Una opción es analizar los datos de Google Search Console y comparar con regularidad los valores de Core Web Vitals de los accesos a través de URLs cortas y de los accesos directos.
Existen varias técnicas para optimizar el rendimiento de las redirecciones. La primera es introducir redirecciones en el borde. Si el procesamiento de las redirecciones de las URLs cortas se ejecuta en el borde de una CDN como CloudFront, Cloudflare Workers o Fastly Compute, la respuesta de redirección se devuelve desde una ubicación en el borde cercana a la persona usuaria. Así se puede ahorrar la comunicación de ida y vuelta con el servidor de origen. Con una redirección en el borde, el tiempo hasta la respuesta es más corto que con una redirección en el servidor de origen. La segunda es elegir el código de estado HTTP adecuado. Si se usa el 301 (redirección permanente), el navegador puede guardar en caché el destino de la redirección, y mientras esté en caché no se produce la comunicación de ida y vuelta de la redirección. En cambio, el 302 (redirección temporal) sin indicaciones de caché no se reutiliza, por lo que la comunicación de ida y vuelta de la redirección se produce cada vez. Para las URLs cortas con un destino fijo se usa el 301, y para las URLs cortas cuyo destino puede cambiar se usa el 302. La tercera es aprovechar DNS Prefetch. Si se resuelve de antemano el dominio de destino de la URL corta con `<link rel="dns-prefetch" href="//example.com">`, se acorta el tiempo de resolución DNS en el momento de la redirección.
La supervisión y la medición de las cadenas de redirecciones son una tarea para seguir revisando el rendimiento. En el panel Network de Chrome DevTools se pueden comprobar el número de saltos y la latencia de las redirecciones, pero en operaciones a gran escala también se usa la supervisión automática. Una opción es integrar Lighthouse CI en el pipeline de despliegue y ejecutar con regularidad pruebas de rendimiento que incluyan accesos a través de URLs cortas. Un mecanismo que avise cuando la latencia de redirección supere un umbral sirve como pista para darse cuenta de los retrasos. Si se introduce una herramienta de Real User Monitoring (RUM) (el informe de Web Vitals de Google Analytics 4, New Relic Browser, Datadog RUM, etc.), se puede medir de forma continua el rendimiento de las redirecciones en los entornos reales de los usuarios. También se puede analizar por región / dispositivo / entorno de red.