Redirect Latency: What It Is, What Causes It, How to Cut It

Redirect latency is the extra time a visitor waits because a URL sends the browser somewhere else before the real page starts loading. Every redirect forces the browser to make another HTTP request, so the delay is real, but one clean redirect is usually small. The damage comes from chains, slow servers, and redirects placed where the browser cannot do anything else while it waits.

This guide explains where the delay comes from, how to measure it on your own links, how to reduce it, and when a redirect is still the right tool.

What redirect latency actually is#

When you type a URL or tap a link, the browser asks a server for a document. If that server answers with a redirect (a 301, 302, 307, or 308 status plus a Location header), the browser has to start again at the new address. Chrome’s performance documentation^[1] describes redirect latency as the delay added to page loading because of that second request.

The Lighthouse documentation puts the cost in plain terms: the extra trip across the network can delay loading by hundreds of milliseconds^[2]. That is the upper end of what people notice, and it depends heavily on what happens during the trip.

A redirect is not just one round trip. Depending on the situation, the browser may also need to:

1. Resolve DNS for the new hostname.
2. Open a new TCP connection.
3. Complete a TLS handshake for HTTPS.
4. Send the request and wait for the server to answer.

When the redirect stays on the same host, the browser can often reuse the connection and skip steps 1 to 3. When it jumps to a different host, which is exactly what a short link or a domain change does, all of those steps can run again. That is why the same status code can cost very different amounts of time on different links.

How much delay does a redirect add?#

There is no single number, and any article that gives you one is averaging over conditions that may not match yours. The delay depends on:

• Distance. A visitor in Singapore hitting a server in Virginia pays for every round trip in physical latency.
• Connection setup. A redirect to a new hostname adds DNS and TLS work on top of the request itself.
• Server think time. A redirect handled by a busy application (a CMS that boots PHP, a rules engine that queries a database) answers slower than one answered by a lightweight edge service.
• Network quality. Mobile networks with high round-trip times multiply every hop.
• Caching. A cached redirect can be answered without a network request at all.

The practical rule is to think in hops. One hop is a modest, usually tolerable cost. Each additional hop pays the whole bill again, which is why Lighthouse fails a page that has two or more redirects^[2] in its multiple-redirects audit.

To see how real redirect services behave, our redirect speed test measures how quickly a given redirect answers, and we have published a ranking of slow URL redirects so you can compare what typical results look like.

What our redirect speed benchmark shows#

Our redirect speed benchmark^[3] times real redirects every hour. Over the seven days from October 27 to November 3, 2026, it measured 27 providers from Washington, D.C., Frankfurt and Tokyo: the time to first byte of each redirect over a fresh connection, without following it. The median per provider ranged from 9 ms for Amazon CloudFront to 586 ms for Apache, and RedirHub's was 15 ms. The same single hop can cost a visitor under 10 ms or more than half a second, depending on who answers it, before any chain multiplies it.

Why latency is not only a speed problem#

Redirect time also hides from some of the tools teams rely on. web.dev’s guidance on Time to First Byte^[4] notes that redirects can affect TTFB, and that lab tools often measure only the final URL, missing that extra delay. A page can look healthy in a synthetic test and still feel slower to real visitors who arrive through a redirect, such as from an ad, a printed code, or an old bookmark.

What makes a redirect slow#

Most slow redirects trace back to one of four causes.

Redirect chains#

A chain happens when URL A redirects to B, which redirects to C. Each hop is a fresh request, and each can involve a new connection. Chains rarely get designed on purpose. They accumulate: an HTTP to HTTPS rule, then a non-www to www rule, then a trailing-slash rule, then a campaign short link pointing at an old URL that was itself migrated last year.

The cost is not linear in how users feel it, either. The more hops, the more chances for one slow server or one dropped connection to stall everything.

Slow origin servers#

If a redirect is produced by your web application, the visitor waits for the whole stack to wake up just to be told to go elsewhere. Redirects handled inside a heavy CMS, a plugin, or an application router answer slower than a dedicated redirect layer built to do one thing.

Browser-based redirects#

Server redirects send the instruction in the response headers, so the browser acts on it immediately. Meta refresh tags and JavaScript redirects are different: the browser must download the page, parse it, and run the script before it learns it should leave. That adds rendering work on top of the network trip, and it is why a visible pause before a page changes usually points to a JavaScript redirect.

Distance and connection setup#

A study of web latency in Ghana found that DNS resolution was the main bottleneck^[5], while HTTP redirections and TLS handshakes were also important contributors. The study covers 2012 to 2014 in one country, so treat its proportions as an illustration rather than a current benchmark. The lesson holds: when the network is slow or far away, every extra request and every new connection costs more.

How to measure redirect time#

You do not have to guess. There are two good ways to look at it: in the browser for real visits, and from the outside for a specific link.

In the browser with Navigation Timing#

The Navigation Timing API records the redirect portion of a page load separately. According to web.dev’s guide to measuring loading performance in the field^[6], you can use redirectStart, redirectEnd, and redirectCount to quantify how much time went to redirect handling, apart from the final page load.

A minimal approach looks like this:

const nav = performance.getEntriesByType('navigation')[0];
const redirectTime = nav.redirectEnd - nav.redirectStart;
console.log(redirectTime, nav.redirectCount);

Send those values to your analytics along with the landing page and traffic source. Two patterns to look for:

• A redirectCount above 1 on a meaningful share of visits means you have chains.
• A high redirect time from one campaign or channel points to a specific short link or domain rule worth fixing.

Keep in mind that the API reports on redirects within the navigation it can see. Cross-origin redirects can be limited by browser security rules, so for those links external testing is the more reliable view.

From the outside, one link at a time#

For a specific URL, trace the full path. A command-line request with curl -sIL prints every hop and its status code, and our redirect checker traces the same chain from your browser. Browser developer tools show it in the Network panel when you enable “Preserve log”. For timing, repeat the test from more than one region, because a link that feels instant in your office may be slow for the audience you are actually paying to reach.

Our redirect speed test is built for this check. Enter a link and compare how fast it answers.

How to reduce redirect latency#

The fixes are mostly about removing work, then making the remaining work cheap.

1. Link straight to the final URL#

The fastest redirect is the one that never happens. Chrome’s guidance^[1] says optimizing the initial document request improves performance, and that eliminating redirects reduces document latency. Audit your internal links, navigation, sitemaps, canonical tags, and email templates, and update each to the current destination rather than relying on an old redirect to catch it.

This is the part you control completely. As web.dev explains^[7], same-origin redirects are within a site owner’s control, while cross-origin redirects typically are not. Fix the former first. For a deeper look at how the status codes differ in behavior, this comparison of 301 and 302 redirects^[8] helps you choose the right type for each rule.

2. Collapse chains into one hop#

If A goes to B and B goes to C, change A to point directly to C. Do this whenever you migrate, rebrand, or restructure. A good habit is to keep a redirect map and, each time you add a rule, resolve its destination through the map so you never stack a new redirect on top of an old one.

Combine protocol and host normalization too. A request for http://example.com/page should reach https://www.example.com/page in one step, not two.

3. Prefer server-side redirects over browser-based ones#

Replace meta refresh and JavaScript redirects with HTTP status redirects wherever you can. The browser then learns about the move from the headers alone, before it downloads or renders anything.

4. Answer redirects from fast, nearby infrastructure#

If a redirect has to exist, make it cheap. A redirect that is served by a lightweight layer close to the visitor avoids the wait for your application to boot and shortens the physical round trip. This is the case for handling redirects outside your main web server, so a traffic spike on your site does not slow your links and a slow site does not slow your redirects. RedirHub is built this way: redirects are served from 130 Global PoPs, each answering from its own copy of the configuration, apart from the dashboard and API.

5. Use caching where it is safe#

Browsers can cache permanent redirects, so a returning visitor skips the trip entirely. The Ghana study found that caching redirects could improve overall page load time by about 20%^[5] in the conditions it examined, and named DNS and redirect caching as key strategies for cutting perceived latency. The trade-off is flexibility: a redirect cached for a long time is harder to change. Use permanent, cacheable redirects for destinations that will not move, and temporary ones for links you expect to edit.

6. Keep DNS and TLS lean#

Because a cross-host redirect can trigger new DNS and TLS work, fast DNS hosting and modern TLS configuration reduce the cost of every hop you cannot eliminate. Make sure certificates are valid and renew automatically, since a certificate error on a redirecting domain turns a delay into a broken experience.

When to point directly and when to keep a redirect#

The rule of thumb is simple: if you control the link and the destination is stable, point directly. If the link needs to outlive the destination, keep the redirect.

Point directly to the final URL when:

• The link lives on your own site (navigation, footers, blog posts, product pages).
• You are updating old internal references after a migration.
• The link is in a place you can edit in minutes, like an email template or an ad.

Keep a redirect when:

• The asset is printed or hard to change. Packaging, brochures, posters, and QR codes cannot be reprinted every time a landing page moves. A redirect lets the printed link stay the same while the destination changes.
• You are migrating. Old URLs have inbound links and bookmarks. Redirecting each old URL to its closest new equivalent protects visitors and search visibility.
• You need tracking. A redirect is the natural point to count clicks and scans by channel, device, or location.
• You want a consistent brand. Links on your own domain build trust and stay under your control instead of living on someone else’s shared domain.
• You are testing. Redirects can split traffic among landing page variants. Our guide on A/B testing landing pages with redirects shows how.

The point is not that redirects are bad. They are infrastructure, and infrastructure should be fast and invisible. One well-served redirect that gives you flexibility and data is usually worth its small cost. Three redirects stacked by accident are not.

A quick audit you can run this week#

You can find most latency problems in an afternoon.

1. List your high-traffic entry points. Campaign links, printed QR codes, email links, top backlinks, and your homepage variants (http, https, www, non-www).
2. Trace each one. Record the number of hops and the final URL. Anything with two or more hops goes on the fix list.
3. Check the type of each hop. Flag meta refresh and JavaScript redirects for replacement with server-side ones.
4. Time them from more than one region. Note the slowest and see whether the delay sits in the redirect or in the destination.
5. Fix at the source. Update the link to the final URL, or rewrite the rule so it points directly to the end of the path.
6. Add monitoring. Send redirectCount and redirect time from Navigation Timing to your analytics, and review them after each migration or campaign launch.

We cover the same ground from another angle in our guide to redirect speed and how to avoid slow redirects, which ends with a redirect speed checklist.

Our perspective on redirect latency#

Keep the flexibility without the slowdown#

If you manage campaign links, printed QR codes, or domain migrations, you need redirects, and you want them to be quick and easy to change. RedirHub lets you run branded links and domain redirects on your own domain with SSL handled for you, and edit destinations without touching what is already printed or published. Dynamic QR codes work the same way, so a code on a package keeps working when the landing page changes.

Plans start with Core at $49 per month and Pro at $119 per month; Enterprise is set by contract. Pro add-ons include Single Sign-On at $200 per month, Custom Name Servers at $100 per month, and a Dedicated Cluster at $300 per month. See the current details on the pricing page.