Redirect Chains: The Hidden Delay Before the First Byte

A redirect chain rarely forms on purpose. It grows over time because each individual rule seems sensible on its own. First HTTP is redirected to HTTPS because the site should be served encrypted. Then a second rule redirects the non-www variant to the www variant so that there is only one canonical address. After a relaunch, a third rule is added that maps old URL structures to new ones. Finally a shop system such as Shopware CE or a CMS adds a fourth redirect, for instance from a URL without a trailing slash to the variant with one. Each rule is understandable on its own, yet in sum a single request passes through four stations before it reaches its destination.

The problem worsens because redirects trigger one another. If someone opens http://example.com without www, the HTTP-to-HTTPS rule fires first and redirects to https://example.com. There the www rule takes over and forwards to https://www.example.com. From there the slug rule points to the final address with a trailing slash. A single user request thus turns into three or four consecutive redirects, each with its own round trip. The order of the rules matters too: a poorly sorted server configuration can create a chain where a single combined rule would have been enough. The first step toward a solution is therefore to make the actual chain visible instead of relying on the assumption that there is only one redirect.

Not every redirect is the same. The HTTP standard distinguishes several status codes with different meanings (IETF RFC 9110). Code 301 signals a permanent move: the resource is definitively found at the new address and search engines transfer the ranking value to the target. Code 302 stands for a temporary redirect in which the original URL remains authoritative. For permanent moves after a relaunch, 301 is therefore the right choice, while 302 is only intended for genuine intermediate states such as a temporary maintenance page. Anyone who accidentally uses 302 for a permanent move risks search engines continuing to prefer the old address (Google Search Central).

Codes 307 and 308 complete this picture for modern applications. Unlike 301 and 302, they make sure the HTTP method is preserved: a POST is forwarded as a POST and not silently turned into a GET. Code 308 is the permanent counterpart to 301 with this additional assurance (IETF RFC 7538) and suits APIs and form processing. For pure loading time the choice of code is secondary, because each of these codes creates the same additional round trip. What matters is the effect on search engines and application logic. In a structured technical analysis we therefore check not only the number of redirects but also whether the appropriate status code is set in each case.

Before a chain can be dissolved, it has to become visible. The simplest tool is a command line call that follows a redirect and logs every station. The command curl -IL https://example.com shows every status code and every Location header in sequence, so the complete chain can be read step by step. In the browser's developer tools the network panel makes the same thing visible: every redirect appears as its own entry with status code 301 or 302 before the actual page loads. It is important to start the test from the root address without a slash and without a protocol, the way a user types it, because that is exactly where most unnoticed chains arise.

Not every redirect carries the same weight. The most important are the chains on the main path, that is, when the home page and the most important landing pages are opened, because that is where the delay hits the most visitors and acts directly on entry performance. Second come redirects on frequently linked campaign and ad landing pages, because paid traffic is especially sensitive to every additional wait. Only after that follow rarely accessed legacy addresses, whose redirect may remain in place but should also point straight at the destination. This order ensures that the largest share of the time saved is realized first, with the least effort.

The effort of such a cleanup is manageable, yet the effect is immediately noticeable. Because the time saved is spent entirely before the first byte, perceived speed improves for every single request, regardless of the device. Combined with client-side precaching for return visits and a solid server configuration, this creates a loading path without unnecessary detours. We take on the complete review of your redirects as part of our performance services and deliver a prioritized list of concrete measures rather than a blanket sweep.