Redirect Speed: Why Redirects Are Slow and How to Fix Them

Direct Answer
A single redirect served close to the visitor adds only tens of milliseconds. Redirects get slow when they are chained (each hop is another request, and often another connection), when they run inside a slow application instead of at the server or edge, or when the server is far from the visitor. Point every redirect straight at the final URL, including https, the right host (www or not) and the trailing slash, run it at the server or edge, and test the result with a redirect speed test.
Does a redirect slow down your website?#
A little, every time. Before the browser can start loading the real page, it has to send a request to the old URL, wait for the redirect response and then start again at the new address. That time is part of the page load: Google's Time to First Byte metric counts redirect time as its first phase, and treats 0.8 seconds or less as a good TTFB[1]. Every millisecond a redirect takes is a millisecond less for everything else.
One fast redirect is rarely the problem. Several in a row are: Lighthouse flags a page with two or more redirects, because each extra round trip can delay loading by hundreds of milliseconds[2], especially on mobile networks.
Search engines follow redirects too. Google says Googlebot generally follows 10 redirect hops[3], so a short chain will still be crawled, but every hop is another request for the crawler and another chance for something in the chain to break.

What makes a redirect slow#
A redirect response is tiny, so its time is almost all waiting: looking up the domain, opening a connection, the HTTPS handshake and the server deciding where to send the visitor. These are the usual reasons that adds up:
| Cause | Why it costs time | Fix |
|---|---|---|
| Redirect chain | Each hop is a full request and response; a hop to another host also needs a new DNS lookup, connection and TLS handshake | Point the first redirect straight at the final URL |
| Destination missing https, www or the trailing slash | The destination site adds its own redirect to fix the URL | Copy the exact final URL into the redirect rule |
| Server far from the visitor | Every round trip crosses the distance again, several times per hop | Serve redirects from a CDN or edge network close to visitors |
| Redirect handled by the application | A CMS plugin or app code has to start, load settings and often query a database before answering | Move redirects into the web server, CDN rules or a redirect service |
| Meta refresh or JavaScript redirect | The browser has to download and start rendering a page before it can leave it | Use an HTTP 301 or 302 instead |
| Plain http first | http to https is an extra hop on every first visit | Link to https URLs and enable HSTS on your site |
Redirect chains: the most common cause#
A redirect chain is a redirect that lands on a URL which redirects again. Most are accidental: someone sets up a redirect to https://mybrand.com, but the site itself lives at https://www.mybrand.com/en/, so the visitor bounces twice more before seeing anything.
It happens far more often than people expect. When we checked a sample of active domain redirects on our platform, about one in three sent visitors to a destination that redirected again. The extra hop was split fairly evenly between adding or removing www, a path change on the same site (a trailing slash, a language folder or a login page), and a move to a different domain altogether (RedirHub platform data, October 2026). None of those hops were needed: copying the final URL into the redirect removes them.
How to find and fix a redirect chain#
- Enter the old URL in our redirect speed test. It lists every hop with its status code and shows the hop count.
- If there is more than one hop, copy the final URL shown under "Where it lands".
- Change the redirect's destination to that exact URL: https, the same host (with or without www) and the same trailing slash.
- Update internal links, canonical tags and your sitemap so they use the final URL too, instead of going through the redirect.
- Test again. The result should show one hop and a 200 at the end.
Is your redirect working? Enter your domain. You'll see the status code (301 or 302), where it lands, whether HTTPS is valid, and how fast it answers from Washington, Frankfurt and Tokyo, ranked against every redirect tested in the last 7 days.
Test my redirectChains pile up after every site move, because new redirects get added on top of old ones. When you plan a website migration, repoint the old redirects at the new final URLs instead of chaining them. If a redirect doesn't work at all, see why a 301 redirect isn't working.
How to make redirects faster#
- One hop, always. This is the biggest win and costs nothing.
- Redirect before the application. Rules in Nginx, Apache, your CDN or a redirect service answer before any app code runs. A redirect plugin that loads your whole CMS first is the slowest place to do it.
- Answer close to the visitor. A redirect from a single server in one region is quick nearby and slow on the other side of the world. An edge network answers from the nearest location.
- Use HTTP redirects, not meta refresh or JavaScript. A 301 or 302 is answered in one short response; a page that redirects itself has to load first.
- Skip the http hop. Link to https URLs, and turn on HSTS on your website so returning browsers go straight to https without asking the network first.
- Pick 301 when the move is permanent. Both answer equally fast, but browsers can cache a 301, so repeat visitors may skip the request altogether.
How fast should a redirect be?#
Our redirect speed test times only the redirect response (the time to its first byte, over a fresh connection) from Washington, D.C., Frankfurt and Tokyo, and ranks it against every redirect tested in the last seven days. On 24 October 2026 the seven-day average was 157 ms. By provider, medians ranged from about 10 ms for the largest CDNs to over 500 ms for the slowest short-link services, and RedirHub's own redirect answered in 17 ms. Some providers had only one or two URLs tested, so read the provider list as a guide, not a league table.

As a rule of thumb, a redirect under 100 ms won't be noticed. A few hundred milliseconds is worth fixing on pages where speed matters, such as ads, email campaigns and mobile traffic. And a chain multiplies whatever each hop costs.
RedirHub: fast redirects without running a server#
If the domains you redirect aren't hosted anywhere (old brands, campaign domains, typo domains), RedirHub answers the redirects for you from 130 global edge locations, close to each visitor, in a single hop to the destination you set. You change only the root and www records, so DNS and email stay where they are, and both get automatic HTTPS issued and renewed for you.
| Your own server or CMS plugin | RedirHub | |
|---|---|---|
| Where the redirect is answered | Wherever the server is | 130 global edge locations, close to each visitor |
| HTTPS for the old domain | You install and renew certificates | Issued and renewed automatically for root and www |
| Paths | Rewrite rules you maintain | Keep the path, or map each old URL to its own new page |
| Redirect types | Whatever you configure | 301, 302, 307, 308 and frame redirects |
| Many domains or URLs | One config file or plugin screen | Several source domains per redirect; CSV import on every plan |
| Visibility | Server logs | Clicks and unique visitors with bots filtered out; DNS re-checked every 10 minutes |
| Price | Your hosting | From $49/month (Core), 14-day free trial |
That is most useful when you look after many domains: a portfolio of forwarded domains, or thousands of old URLs loaded with a bulk CSV import. If your site already sits behind a CDN with redirect rules, those are just as fast, and you don't need another service for redirects on that site.
Redirect speed checklist#
- Every redirect reaches its final page in one hop.
- Destinations use the exact final URL: https, the right host and the right trailing slash.
- Redirects run in the web server, CDN or a redirect service, not in page code.
- Internal links, canonicals and sitemaps point at final URLs.
- Key redirects are re-tested after every site change or migration.
How fast is your redirect? Test one URL and see its first-byte time from three continents, every hop it takes, and how it ranks against every redirect tested in the last 7 days.
Run the speed testSources
Frequently asked questions
Slightly. The browser has to request the old URL and receive the redirect before it can load the new page, and that time counts toward Time to First Byte. A single redirect answered close to the visitor usually costs only tens of milliseconds; chains and distant servers are what make it noticeable.
A fast redirect answers in well under 100 ms. On 24 October 2026 the average across redirects tested in our redirect speed test over the previous seven days was 157 ms, with the fastest providers around 10 to 20 ms and the slowest over 500 ms.
More than one. Lighthouse flags pages with two or more redirects, and every extra hop adds another request. Google says Googlebot generally follows 10 redirect hops, but aim for a single redirect straight to the final URL.
Redirect chains, destinations that redirect again (missing https, www or a trailing slash), servers far from the visitor, redirects handled by a CMS plugin or app code instead of the web server or CDN, and meta refresh or JavaScript redirects that need a page to load first.
The response itself is just as fast. The difference is caching: browsers can cache a 301, so a repeat visitor may skip the redirect request, while a 302 is normally requested again each time. Choose by meaning: 301 for permanent moves, 302 for temporary ones.
An HTTPS connection needs a TLS handshake, which adds a round trip, so a redirect over https takes a little longer than the same redirect over plain http. The bigger cost is an extra http-to-https hop; link to https URLs and enable HSTS so browsers go straight to https.
Enter the URL in a redirect speed test that times the redirect response itself, from more than one location, and lists every hop. RedirHub's free redirect speed test measures from Washington, D.C., Frankfurt and Tokyo and ranks the result against every redirect tested in the last 7 days.
RedirHub answers redirects from 130 global edge locations, close to each visitor, in a single hop to the destination you set, with HTTPS issued automatically. You only change the root and www DNS records, so nothing else about your domain moves.

TC is the Operations Manager at RedirHub, leading the company’s operational strategy and execution to ensure reliable, scalable redirect infrastructure. He oversees internal processes, cross-team coordination, and platform readiness while supporting customers through complex redirect implementations. With a strong understanding of large-scale domain operations and real-world edge cases, TC plays a key role in aligning product and customer success to deliver stable, high-performance redirection solutions.
Related Articles
View All Articles


