Do Redirects Impact Your Website’s Speed?
August 02, 2019
A common question we hear from clients’ dev teams is if they can remove redirects in order to speed up the website. The thinking is that removing redirects can reduce overhead on the server and make the website load more quickly. That seems to make sense—but do redirects have that kind of impact? At the same time, Google has suggested removing landing page redirects to reduce a website’s speed. I wanted to put both concerns to the test: Do redirects add to a website’s overhead enough to slow it down? Do landing page redirects affect a website’s speed? If so, how much?
- Server Overhead
- Landing Page Redirects
- Final Thoughts & Takeaways
- Methodology Notes
The .htaccess file is a configuration file on Apache servers (learn more). You can place a variety of directives on this file to control varying aspects of how the website will operate. Those directives act as instructive statements and can include password protection directives for certain directories, specifications on handling errors, instructions to prevent access to certain files, and, among many other directives, redirects.
Putting redirects on the .htaccess file is fairly simple, making this a common method for establishing redirects on Apache servers. For example, I want anybody who types in matthewedgar.net/about-me to be redirected to my home page. To handle this redirect, I can use this line of code:
redirect 301 /about-me /
That line begins by saying we have a redirect directive that should return a 301 response code. Next, the directive says that if the requested URL is about-me, the server should reroute the bot or person making that request to /.
The catch, though, is that redirect directives are read in sequential order. As well, the server reads these directives on the .htaccess file every time the website is loaded. If you have a thousand redirects, then the server needs to read all thousand redirect directives every time a request is made to access the website. It is for this reason that .htaccess redirects have the potential to impact speed: if there are lot of redirects, it could take a while for a server to read through all those redirects.
But how many redirects do you need 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.
Time to First Byte
The biggest impact redirects could have on speed is by adding to 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.
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 Redirects||Time to First Byte (Seconds)||TTFB Above No Redirects (Seconds)||TTFB % Increase From No Redirects|
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 last year 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.
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.
Total Load Time Compared to Total Redirects
|Total Redirects||Load Time (Seconds)||Load Time Above No Redirects (Seconds)||Load Time % Increase From Redirects|
Start Render Compared to Total Redirects
|Total Redirects||Start Render Time (Seconds)||Start Render Above No Redirects (Seconds)||Start Render %Increase From Redirects|
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 Redirects||Load Time Minus TTFB||Start Render Minus TTFB|
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 .htaccess file makes no difference. Rather, this is an issue of the server having to sequentially read all one million redirects—if there aren’t redirects to read, the server doesn’t need to spend hardly any time at all.
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 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. So, I could use a regular expression (or regex) instead. In this case example, that could be:
RewriteRule ^blog/2019/(.*)$ /articles/$1 [L,R=301]
In the above, we’re starting the RewriteRule, then specifying a pattern for the server to match. In this case, the server is looking for anything that begins with blog/2019. If the server finds as a match, as it would for mysite.com/blog/2019/blog-post-title, it will redirect anybody 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 directives, [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 that we end up affecting our website’s speed.
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 directive that affects every URL on the website instead of having to create redirect directives for each individual URL.
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 run 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.
Unlike the .htaccess redirect directives, the redirects in the Redirection plugin don’t have to be read sequentially when the website is loading. Instead, the plugin saves all the redirects to a database and when a page is requested, the plugin checks the database for the requested URL. If the requested URL is found in the database, that means there is a redirect defined for it 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 Redirects||Load Time (Seconds)||Start Render Time (Seconds)||Time to First Byte (Seconds)|
Any link you click on will take you to a landing page. However, that landing page the link referenced might be redirected elsewhere. 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 two pages instead of one: the page you clicked on and the page that you were redirected to (for simplicity, let’s call the page you were redirected to the “final destination” of the redirect). This can become a bigger problem with redirect chains—redirect chains happen when you have more than two hops in 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—that’s four redirects before the page users want is available.
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?
(An important side note: redirect chains do affect SEO. In this article, I’m strictly considering implications of 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.)
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 comparison sake, 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.
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. However, one redirect—strictly from a speed standpoint—may not be the most concerning issue (but, again, there are SEO reasons to worry about even one redirect).
Redirect Chains Compared to Speed
|Redirects Before Final Destination||Load Time (Seconds)||Start Render (Seconds)||TTFB (Seconds)||TTFB Above Redirects (Seconds)|
|0 (final destination)||0.866||0.3||0.194||–|
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 or by delaying the load of the final destination page.
Impacts on Server Overhead
Yes, but only under very specific circumstances. If you have 50,000+ redirects in an .htaccess file, you probably should revisit those redirects to see what redirects could be removed or simplified using regular expressions. But if you have 50,000+ redirects in a plugin like Redirection, that isn’t impacting your speed much, if at all.
The other takeaway is that database methods of handing redirects operate more quickly on the balance simply because they don’t require reading each line of code individually. So, if you are going to have lots of redirects, or if you think that is a possibility, it might be worth using that method for controlling redirects from the start.
Ultimately, though redirects tend not to be that big of a deal for speed unless you have (or are going to have) lots of redirects in place. 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
Redirects before reaching a page present a bigger, and more immediate, problem for a web page’s load time. The more redirects you have, 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, 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.
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.
Yes, redirects do add to a website’s speed. There are two ways redirects can affect speed: by adding to the server overhead or by delaying the load of the final destination page.
- 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.
- 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.
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. If you have questions or you’d like to view the full data, please contact me.