Skip to content

Do Redirects Impact Your Website’s Speed?

March 03, 2022

A common question we hear from developers is if they can remove redirects in order to speed up the website. Will removing redirects reduce overhead on the server and make the website load more quickly? Alternatively, Google has suggested removing landing page redirects to reduce a website’s speed.

In this article, let’s review and test out the assumptions behind two key questions: Do redirects add to a website’s overhead enough to slow it down? Do landing page redirects affect a website’s speed?

TLDR

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:

  • 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.
  • 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.

Table of Contents

.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 requestor. Before any data can be sent back to the requestor, the server must read through the .htaccess file directives in order to understand how to respond to the request.

In the case of the TTFB, my tests found a 24% increase 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 adds .225 seconds to the 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 a redirect 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, 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 the document complete. The start render is the first time something appeared 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 basically the same no matter how many redirects there are, save for minor fluctuation that likely has 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 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 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 similar 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 one. 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, 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. But what makes this beneficial is the regex of (.*)$, which tells the server to grab anything after “2019/” and put it where the $1 is located after “/articles/”.

The final bit 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. Second, the “L” tells the server to stop processing, 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 individual URL.

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 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

Landing Page Redirects

What Are Landing Page Redirects

When you click on a link, the browser makes a request to the server and the server responds by returning the requested file. However, the URL specified in that link you clicked might not be the file loaded. Instead, this file might be redirected elsewhere. When a redirected URL is requested, the server has to process the redirect and then return the file redirected to instead of the original file requested. This is called a landing page redirect. In a now deprecated article, Google discusses why landing page redirects add to load time:

“Redirects trigger an additional HTTP request-response cycle and delay page rendering. In the best case, each redirect will add a single roundtrip (HTTP request-response), and in the worst it may result in multiple additional roundtrips to perform the DNS lookup, TCP handshake, and TLS negotiation in addition to the additional HTTP request-response cycle.”

In other words, you must load multiple pages. If the page you clicked on redirects, then the server has to load the page you clicked to and then load the page that you were redirected to. The page you eventually reach after all redirects are processed is called the “final destination” of the redirect. This can become a bigger problem with redirect chains, where there are multiple redirects to process. 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—that’s four redirects (also called redirect hops) before the final page is requested and can be returned to the browser.

The question, then, is regardless of the redirect method (.htaccess redirect, RewriteRule, Redirection plugin, etc.), how do the redirects that happen before the final destination affect the final destination page’s speed? Does this get worse as there are more redirects required before the final destination?

What Impact Do Landing Page Redirects Have on Speed

When looking at the speed test, the most telling sign that chains create a problem is by looking at the waterfall. In this waterfall, you can see that page-1, page-2, page-3, page-4, and page-5 must be loaded before test3.html (the final destination) is loaded. The final destination page doesn’t take that much time to load (.354 seconds). For sake of comparison, on the first request, page-1, that has .047 seconds to look up the DNS and another .065 seconds to establish the connection—both of those would be added to the final destination page had it been loaded without the redirect. That means the load time of the test page would have been .466 seconds had it not been for the redirects, a very respectable speed. But the five redirects added .331 seconds to that page’s load.

301 302 redirect chain

The speed test tool I was using limited how many redirects there could in the chain before failing, so I stopped my tests at 15. That’s okay because at 15 redirects, we’ve added 1.1 seconds to our TTFB—that is a sizable concern for a website’s speed. As well, if you have more than 15 redirects before the final destination, chances are browsers may not support the redirect chain 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.

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.

Redirect Chains Compared to Speed

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

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 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.

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 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.

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. If you have questions or you’d like to view the full data, please contact me.

You may also like

How To Manage Parameters

Parameters can create duplicate content, slow down website crawling, and disrupt rankings. What are the best ways to avoid these problems? In this article, we’ll review how to find and manage parameters on a website.

Performing Regular Tech SEO Checks with SE Ranking

Although a Tech SEO Audit can be completed using a variety of tools, in this post, I want to walk through how we can do each of these tasks using SE Ranking’s audit tool.

How To Fix 404 Errors On Your Website

How do you find the 404 errors on your website? Once found, how do you fix the 404 errors? What tools can help? Find out in this in-depth 404 guide!