Skip to content

Do Redirects Impact Your Website’s Speed?

By Matthew Edgar · Last Updated: January 19, 2024

There are two ways redirects can affect a website’s speed: by adding to the server overhead or if landing page redirects are used. To find out if redirects impact site speed, I will review and test out the assumptions behind two key questions:

  • Do landing page redirects affect a website’s speed?
  • Do redirects add to a website’s overhead enough to slow it down?

Quick Summary

The details and data are provided below. The short answer is that, yes, redirects can add to a website’s speed. Here are a few key takeaways from this data:

  • If redirects impact speed, they will affect the Time To First Byte (TTFB). If your TTFB is low, chances are good that redirects aren’t what’s causing your website to load slowly.
  • Redirect chains have a notable impact on speed, especially after 3-5 redirect hops. Linking to the final destination to skip the chain can reduce a website’s load. If you can’t link to the final destination, link as close to the final destination as possible to avoid too many redirects.
  • Redirects can add overhead and impact a website’s speed if they are contained in the .htaccess file and if there are more than 50,000 redirect directives included.
  • If you have fewer than 50,000 redirects specified on your .htaccess file, don’t worry about the speed implications of redirects adding overhead—there are better ways to improve your site’s speed!
  • If redirects are specified in a database, such as through a WordPress plugin, redirects likely have no impact on speed.

Table of Contents

Landing Page Redirects

What Are Landing Page Redirects

In this context, a landing page refers to any page a visitor or a robot is attempting to load. If that landing page redirects somewhere else, that is referred to as a landing page redirect.

When you click on a link, the browser requests the file from the server and the server responds by returning the requested file. However, with a redirect, the server has to load the requested file, detect that the requested file redirects elsewhere, process the redirect for that requested file, and then load and return the file located at the destination of the redirect. As Google discusses in a deprecated but still accurate article about landing page redirects, this will “trigger an additional HTTP request-response cycle and delay page rendering.” Landing page redirects will impact Core Web Vitals metrics, especially Largest Contentful Paint.

What Impact Do Landing Page Redirects Have on Speed

The impact of landing page redirects will be seen most clearly in the Time to First Byte (TTFB). TTFB is the measure of how quickly the server can return the first byte of data to the page. For example, in ByteCheck, you can see how much time it takes for the server to process a redirect. In the following example, the redirect took 285.19 milliseconds to process.

Impact of redirect time can be seen in TTFB, as measured by ByteCheck

Landing page redirects become a bigger problem with redirect chains. With a redirect chain, there are multiple redirects for the server to process before reaching the endpoint of the redirect. For example, page-1 redirects to page-2, page-2 redirects to page-3, page-3 to page-4, and page-4 redirects to the final destination of the redirect—that’s four redirects (also called redirect hops) before the final page is requested is returned.

We can see the impact of redirect chains in the following screenshot of a waterfall report generated by WebPageTest. In this example, page-1, page-2, page-3, page-4, and page-5 must be loaded before test3.html (the final destination) is loaded. While the final destination only takes 354 milliseconds to load, the page needed just over 0.8 seconds to load because of the redirects; the redirect chain added almost a half second to the total load time of this page.

Redirect chain speed impacts, as measured by WebPageTest
Redirect chain speed impacts, as measured by WebPageTest

How quickly would the final destination page load if it wasn’t for the redirects? The final destination page itself loaded in only .354 seconds. However, without the redirects, it would have taken more time than that to load the page. To understand how quickly the final destination page would have loaded without the redirects, we need to include the DNS lookup and server connection times.

To get these numbers, we can look at the first request, page-1. This file required .047 seconds for the DNS lookup (the first part of the bar, in green) and another .065 seconds to establish the server connection (the second part of the bar, in orange). Both of those would be added to the final destination page had that page been loaded without the redirect. That means the load time of testpage3.html, without the redirects, would have been .466 seconds (.354 seconds to load the final destination page + .047 seconds for the DNS lookup + 0.65 seconds for the server connection). In total, then, the redirects added .331 seconds to that page’s load.

Redirect Chains Compared to Speed

The more redirects in the chain, the slower the speeds. In a chain of 15 redirects, 1.1 seconds is added to the TTFB—that is a sizable concern for a website’s speed. Also, if you have more than 15 redirects before the final destination, chances are browsers may not support the redirect chain (and Googlebot may not follow all the redirects either).

In looking at the other redirect chain levels from 1-15, the trends are generally not surprising with each redirect increasingly adding to the load time. It begins to get concerning after 3-4 redirects, and anything above 5 redirects is a critical problem to address. One redirect—strictly from a speed standpoint—may not be the most concerning issue but it isn’t a non-issue. Linking directly to the final destination, or at least as close to the final destination as possible, will help improve the load time of that final destination.

Redirects Before Final DestinationLoad Time (Seconds)Start Render (Seconds)TTFB (Seconds)TTFB Above Redirects (Seconds)
0 (final destination)0.8660.30.194
10.9360.40.2670.073
20.9840.40.3220.128
31.0870.50.3980.204
41.1760.60.4760.282
51.4610.70.5470.353
101.5110.8570.663
151.9571.41.3071.113

An important side note: redirect chains do affect SEO. In this article, I’m strictly considering the implications of redirect chains on speed but even if there isn’t a huge impact on speed, redirect chains are not recommended if you care about ranking in search results.

Server Overhead: .htaccess Redirects

How .htaccess Redirects Work

The .htaccess file is a configuration file on Apache servers (learn more) where you can specify a variety of directives that will control varying aspects of how the website operates. Among many other directives, that includes password protection, error handling, blocking access, and, redirects.

Putting redirects on the .htaccess file is fairly simple, making this a common method for establishing redirects on Apache servers. For example, this line of code will redirect matthewedgar.net/about-me to the home page:

redirect 301 /about-me /

That line begins by declaring this is a redirect directive and that should return a 301 response code. Next, the directive says that if the requested URL matches about-me, the server should redirect the request to / (the home page’s URL).

Redirect directives are read in sequential order to determine if one of those directives matches the requested file. If there are thousands of redirect directives, the server will need to review each to see if the redirect is a match. If a match is found, the server will immediately stop reviewing and process the redirect. However, if the requested file is not a redirect, the server will have to review each redirect directive to conclude there is no match.

As well, the server needs to review all of the redirect directives for every file requested. If there are a thousand redirects specified on the .htaccess file, then the server will need to read all thousand directives for every single file requested. If a web page loads 9 images, 2 CSS files, and 3 JS files, that is a total of 15 file requests to load the page (9 images + 2 CSS + 3 JS + the page itself) and for each of those 15 requested files, the server will have to check if the requested file matches one of the redirect directives.

This is why .htaccess redirects have the potential to impact speed: if there are lots of redirects and lots of files requested, the server may require excessive time to review and process all those redirects.

But how many redirects have to be specified before you create so much server overhead that you slow down the website’s load? To find out, I tested load speeds when there were zero to one million redirect directives in the .htaccess file. Let’s review the results and see how .htaccess redirects impact speed.

.htaccess Redirect Impacts on Speed

Time to First Byte

The first thing to check is if redirects impact the Time to First Byte (TTFB). TTFB is the time between the request being made and the server sending the first byte of data back to the browser. Before any data can be sent back to the browser, the server must read through the .htaccess file directives to understand how to respond to the request.

My tests found a 24% increase in TTFB above no redirect directives once 5,000 redirect directives have been added. However, that only represents 0.047 seconds—which isn’t insignificant when it comes to your website’s speed but doesn’t present the largest concern either. After all, bigger gains could be made by adding caching to your website or minifying JavaScript files. As well, this small amount of time could be an error within the speed testing tool used. (All of those same remarks apply to 10,000-25,000 redirects where it adds .115-.116 seconds to the TTFB.)

Where we see a bigger impact on TTFB starts at 50,000 redirects. 50,000 redirects in the .htaccess file added .225 seconds to TTFB, a full 116% increase from the TTFB when there were no redirect directives on the .htaccess file.

Time to First Byte Compared to .htaccess Redirects
Total RedirectsTime to First Byte (Seconds)TTFB Above No Redirects (Seconds)TTFB % Increase From No Redirects
00.194  
2500.186-0.008-4%
5000.19-0.004-2%
10000.193-0.001-1%
25000.2080.0147%
50000.2410.04724%
100000.3090.11559%
250000.310.11660%
500000.4190.225116%
1000000.5890.395204%
2000000.9330.739381%
3000002.0461.852955%
4000003.3333.1391618%
5000003.3883.1941646%
10000004.2474.0532089%

In all my years of working on websites and adding redirects, I have never seen an .htaccess file that contained 50,000 redirects (let alone a million!) but if your .htaccess file does contain this many redirects, it might be time to reconsider each redirect to see if all of those are still necessary.

However, if you have fewer than 5,000 redirects on your .htaccess file, I wouldn’t worry here—there are other ways to optimize your website’s speed. SEOMike conducted a similar test and found consistent results, with a notable jump in TTFB once more than 10,000 redirects were added and an even larger increase at 50,000 redirects.

This article was first published in 2019. Subsequent tests have continued to find similar results. However, the caching provided by certain hosting companies might help to offset the volume of redirects.

Start Render and Total Load Time

TTFB isn’t the only way we can measure the impact. We can also look at the load time and the start render. The load time is the time between the initial request and when the page has finished loading all associated files (images, JavaScript, CSS, etc.). The start render measures the time when something first appears on the screen.

While in both cases the time increases as there are more redirects, the time increase isn’t nearly as substantial as what we saw from the TTFB. This makes sense—removing redirect directives from the .htaccess file is a means of improving the TTFB more than it is a means of improving start render or total load time because redirects slow down the initial connection with the server.

Total Load Time Compared to Total Redirects
Total RedirectsLoad Time (Seconds)Load Time Above No Redirects (Seconds)Load Time % Increase From Redirects
00.815  
2500.8170.0020%
5000.8250.011%
10000.813-0.0020%
25000.8350.022%
50000.8730.0587%
100000.9790.16420%
250001.1820.36745%
500001.1470.33241%
1000001.260.44555%
2000001.6320.817100%
3000002.7051.89232%
4000003.9663.151387%
5000004.0053.19391%
10000004.9544.139508%
Start Render Compared to Total Redirects
Total RedirectsStart Render Time (Seconds)Start Render Above No Redirects (Seconds)Start Render %Increase From Redirects
00.3  
2500.300%
5000.300%
10000.300%
25000.300%
50000.40.133%
100000.40.133%
250000.40.133%
500000.50.267%
1000000.80.5167%
20000010.7233%
3000002.21.9633%
4000003.53.21067%
5000003.53.21067%
10000004.341333%

Redirects Impact TTFB

To more clearly see why it is the TTFB that is affected by the .htaccess file, we can look at the start render and load time with the TTFB factored out. The start render and load time without the TTFB are the same no matter how many redirects there are, save for minor fluctuations that likely have more to do with the speed test tool than the redirects.

Total RedirectsLoad Time Minus TTFBStart Render Minus TTFB
00.6210.106
2500.6310.114
5000.6350.11
10000.620.107
25000.6270.092
50000.6320.159
100000.670.091
250000.8720.09
500000.7280.081
1000000.6710.211
2000000.6990.067
3000000.6590.154
4000000.6330.167
5000000.6170.112
10000000.7070.053

Other Considerations

File Size

In looking at the data above, it might seem like this is simply a file size issue. After all, if your .htaccess file includes 50,000 redirects, that file is going to be large (50,000 redirect directives added 2.75MB to my .htaccess file size in the tests above). Given this, it must be harder for the server to read such a large .htaccess file, and that must be what causes the slowdown.

However, it isn’t a file size issue. To test this, I added one million commented-out directives to the .htaccess file. One million redirects resulted in an .htaccess file that was 58.9MB and one million commented-out lines was 59.9MB (slightly larger). One million redirects had a TTFB of 4.247 while commented-out lines had a TTFB of .393.

In other words, the size of the .htaccess file makes no difference. Rather, this is an issue of the server having to sequentially read all one million redirects. If there are no redirect directives specified, then the server doesn’t need to spend time reviewing and processing those redirects.

Regex Redirects (RewriteRule)

You can also create redirects in the .htaccess file using RewriteRule directives. This operates similarly to the redirect we looked at above but offers more flexibility because, with RewriteRule directives, you can use regular expressions. A regular expression allows you to match several URLs at once instead of specifying individual URLs one by one.

For example, let’s say I want to move my blog posts from a date-based directory (such as mysite.com/blog/2019/blog-post-title) to a directory called articles (such as mysite.com/articles/blog-post-title). If I have 550 blog posts, I could write redirect directives for each blog post. But that would take some time to write those redirects out and, as we’ve seen above, there are implications for creating so many redirects. Instead of one-by-one redirects, a regular expression (or regex) would collapse the 550 redirects into a single statement on the .htaccess file. In this example, the RewriteRule statement would be:

RewriteRule ^blog/2019/(.*)$ /articles/$1 [L,R=301]

In the above code, we’re starting the RewriteRule and then specifying a pattern for the server to match. In this case, the server is looking for any URL that begins with blog/2019. If the server finds a match, as it would for mysite.com/blog/2019/blog-post-title, it will redirect the user over to the /articles/ directory.

What makes this beneficial is the regex capture of (.*)$, which tells the server to grab anything after “2019/” and put it where the $1 is located after “/articles/”. That adds the blog post slug to the /articles/ directory and tells the server where to redirect to.

The final part of this directive, [L,R=301], tells the server two things. First, the R=301 tells the server to send a 301 HTTP response status code to indicate this is a permanent redirect (learn more about 301 redirects). Second, the “L” tells the server to stop processing further directives, which improves the website’s load time.

As a result of all of this, RewriteRule directives (or regex redirects as they are sometimes called) offer us a means of reducing how many redirects are needed. That can help us avoid ever needing to have so many redirects in the .htaccess file. Even if there are no speed implications from having multiple redirects, minimizing the number of redirects will make it easier to manage and update the website.

As well, this also explains why redirects that take people from the www to the non-www version of a site or take people from the http to the https version aren’t a big deal for speed either. Both redirects can be accomplished in one RewriteRule that affects every URL on the website instead of having to create redirect directives for each URL.

CMS Overhead: WordPress Redirection Redirects

How WordPress Redirection Differs from .htaccess

Instead of placing redirects in the .htaccess file, either as RewriteRule or redirect directives, redirects can also be handled through content management systems, like WordPress. We typically recommend Redirection to handle redirects for companies who use WordPress to manage their websites. Using Redirection, you can add the redirect through a form, instead of having to write any code to the .htaccess file. You can also add regular expressions here, similar to how the RewriteRule directive worked in the .htaccess file.

Add New Redirect to WordPress Using Redirection plugin

WordPress Redirection Impact on Speed

Unlike the .htaccess redirect directives, the redirects in the Redirection plugin don’t have to be read sequentially when a file is requested from the website. Instead, the plugin saves all the redirects to a database. When a file is requested, the plugin checks the database to see if the requested file’s URL is contained in that database. If it is found in the database that means there is a redirect and, in that case, the plugin conducts the redirect. (This is a bit different when using regular expressions, though a similar logic applies—regex redirects through Redirection were not used in my tests.)

That means with this plugin, there shouldn’t be as much, if any, impact on speed—which is exactly what my tests showed. Even with up to a million redirects added, there was no difference in load time, start render, or Time to First Byte. You’ll notice that there are some fluctuations within the load time, but those differences are well within the expected difference ranges you’d expect to find when running speed tests.

WordPress Redirection Redirects Compared to Load Time

Total RedirectsLoad Time (Seconds)Start Render Time (Seconds)Time to First Byte (Seconds)
01.9531.50.589
10001.8571.60.613
100002.111.60.595
500001.8711.80.6
1000001.8351.70.54
2000001.9771.60.677
3000002.0131.70.586
4000001.8491.60.612
5000001.811.60.564
10000001.7771.5950.544

Final Thoughts & Takeaways

The main question is: do redirects add to a website’s speed? The short is yes, but that requires a lot of explanation. There are two ways redirects can affect speed: by adding to the server overhead and by delaying the load of the final destination page.

Impacts of Redirected Landing Pages

Reducing redirects before reaching the final destination represents a bigger, and more immediate, opportunity for improving load time. The more redirects you have (the larger the redirect chain), the more requests that must be made to the server and that slows down the page’s overall load. This becomes a problem after only a handful of redirects are present in the chain. Granted, how much impact there will be per redirect will depend on the server—in my case, each redirect added 60-70 milliseconds, but other servers will vary. Regardless of the specific number, some amount of time will be added for each redirect in the chain.

Thankfully, this speed issue is relatively easy to correct—update links to go to the final destination instead of linking to the URL that will redirect to the final destination. That sounds simple, but there are technical restrictions on adding links. As a result, if you can’t link to the final destination and are forced to link into a redirect chain, do your best to link to the page that will take the fewest redirects to reach the final destination page.

Impacts on Server Overhead

Redirects can add to the server overhead, but only when there are a lot of redirects to process, likely more than 50,000, within the .htaccess file. However, using a database to manage redirects, like the Redirection plugin in WordPress, is generally going to operate more quickly because this redirect method doesn’t require reading each redirect directive individually for every page load.

Keep in mind, though, that if you have more than 50,000 redirects specified anywhere, you probably should revisit those redirects to see what redirects could be removed or simplified using regular expressions. There are easy ways to avoid having so many redirects—for example, have a stronger architecture for your website’s content so that you don’t have to alter URLs or add redirects all that often. For the majority of websites, though, there are bigger factors to consider for reducing your website’s load time.

Need Help?

If you’d like help working on reducing your website’s load time, sorting through your website’s redirects to remove chains, or need help identifying links referencing redirects please contact me today.

Methodology Notes

All speed tests were conducted using Web Page Test, set to Denver, Colorado USA – Chrome – Cable. On the .htaccess file overhead test, the total file size of the page tested was 227KB (contained text + an image, no CSS or JS). On the WordPress Redirection test, the total file size of the test page was 652KB (contained text + two images, using default WordPress theme). On the chain test, the endpoint destination page was 227KB and the .htaccess file only contained the redirects needed to create the chain to avoid any overhead. All tests were conducted by me in July 2019. This data was originally published in August 2019 with updates made to the article for clarification in 2022, 2023, and 2024. If you have questions, please contact me.

You may also like

What is Core Web Vitals?

What are Google’s Core Web Vitals metrics? How can these affect your website’s performance? How do you optimize your website?

How to Use a Headless Browser

Learn what a headless browser is, why you should use a headless browser and how to launch a headless browser on your own computer.

Handling Out of Stock & Removed Product Pages

How do you remove products from your website without harming your users or SEO performance—or at least minimize the harm? In this post, Matthew walks through the different options available.