What Each Redirect Hop Costs You

By Holifan, approved 2026-09-19. Drafted with AI from the sources listed below, checked against them automatically, with code examples tested, and approved by the site owner.

This guide is for web developers and site owners who manage redirects. You will learn what each redirect hop costs in performance, how to choose the right HTTP status code, how HSTS can eliminate redundant HTTPS redirects, and how to verify your redirect chains.

Performance Cost of Each Hop

When a browser receives a redirect response, it immediately loads the new URL from the Location header. This means an additional HTTP round-trip before the final content begins. Besides this small performance hit, users rarely notice the redirection. However, every redirect impacts performance, so you should keep their use to a minimum.

Internal redirects are especially costly because they add an extra HTTP request. If you can avoid them by correcting internal links, you should fix those links instead. For example, if your own pages link to an old URL that then redirects to a new URL, update the link to point directly to the new URL. This eliminates one full request-response cycle for every click.

HTTP Redirect Status Codes and Their Meaning

Redirect responses have status codes that start with 3 and include a Location header holding the URL to redirect to. Google treats the two kinds differently: permanent redirects show the new target in search results, while temporary redirects show the source page.

Permanent redirects (301 Moved Permanently, 308 Permanent Redirect) indicate that the original URL should no longer be used. Search engine robots, RSS readers, and other crawlers update the original URL for the resource. Use these when you are sure the redirect will not be reverted.

Temporary redirects (302 Found, 303 See Other, 307 Temporary Redirect) are used when the page is temporarily unavailable at its usual address. Search engine robots and other crawlers do not memorize the new, temporary URL. Use these when the original URL should remain in search results.

The table below summarizes common status codes, method handling, and typical use cases:

CodeTextMethod handlingTypical use case
301Moved PermanentlyGET methods unchanged; others may or may not be changed to GETReorganization of a website
308Permanent RedirectMethod and body not changedReorganization of a website with non-GET links/operations
302FoundGET methods unchanged; others may or may not be changed to GETWeb page temporarily unavailable for unforeseen reasons
303See OtherGET methods unchanged; others changed to GET (body lost)Used after PUT or POST to avoid re-triggering the operation on refresh
307Temporary RedirectMethod and body not changedWeb page temporarily unavailable; better than 302 when non-GET operations are available

The key difference between 301/302 and 308/307 is method handling. 301 and 302 may change non-GET methods to GET, while 308 and 307 preserve the method and body. Use 308 or 307 when the redirect involves non-GET operations.

Alternative Redirect Mechanisms and Precedence

HTTP redirects are not the only way to define redirections. You can also use HTML <meta> redirects and JavaScript redirects. However, they have different execution orders.

HTTP redirects always execute first because they exist before the page is even transmitted. JavaScript redirects execute next, before HTML redirects. This is because the <meta> redirect happens after the page is completely loaded, which is after all scripts have executed. HTML redirects execute only if there were no HTTP or JavaScript redirects that executed before the page was loaded.

Here is an example of an HTML meta refresh redirect:

<meta http-equiv="Refresh" content="0; url=https://example.com/" />

And a JavaScript redirect:

window.location = "https://example.com/";

When possible, use HTTP redirects and avoid adding <meta> element redirects. If someone changes the HTTP redirects but forgets to change the HTML redirects, the redirects will no longer be identical, which can cause an infinite loop or other problems.

HTTPS Redirects and HSTS Optimization

If your host accepts insecure HTTP requests, it should respond with a permanent redirect (301) to an https URL. The browser then makes a new request using HTTPS. That HTTPS response should include the Strict-Transport-Security header.

Example response header:

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

The max-age directive specifies how many seconds the browser should remember that the host must be accessed only via HTTPS. The optional includeSubDomains directive applies the policy to all subdomains as well.

After the browser receives this header, it adds the host’s domain name to its persistent list of HSTS hosts. On future attempts to load http:// URLs, the browser automatically upgrades the scheme to https without requiring a redirect. This eliminates the extra round-trip of the 301 redirect for subsequent visits.

Note that the Strict-Transport-Security header must be sent over HTTPS only. Browsers ignore the header if sent over HTTP to prevent a man-in-the-middle attacker from altering or adding it.

Common Mistakes

How to Verify the Result

Check each redirect response’s status code and Location header to confirm it matches the intended permanent or temporary redirect type. For example, a permanent redirect should have a 301 or 308 status code, and the Location header should point to the new URL. A temporary redirect should use 302, 303, or 307.

If a redirect loop occurs, the server may respond with a 500 Internal Server Error, and browsers show an error message. Sometimes the server cannot detect the loop because it spans several servers each without the full picture. In that case, browsers will detect it and display an error such as “This Webpage has a redirect loop.” Monitoring for these signals can reveal loops.

For HTTPS redirects, verify that the first HTTP request returns a 301 and that after loading once, subsequent HTTP URLs are upgraded by the browser without a redirect. You can test this by clearing the browser’s HSTS cache, loading the http:// URL once, and then loading it again to see if the browser directly uses https.

Sources

Check your own site with the Headers, Robots.txt & Sitemap Checker.