Do Redirects Impact Your Website’s Speed?

By Matthew Edgar · Last Updated: September 13, 2023

Can you remove redirects to speed up your website? There are two ways redirects can affect a website’s speed: by adding to the server overhead or if landing page redirects are used.

In this article, let’s 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
  • What Impact Do Landing Page Redirects Have on Speed
• Server Overhead
  • Server Overhead: .htaccess Redirects
    • How .htaccess Redirects Work
    • .htaccess Redirect Impacts on Speed
    • Other Considerations
  • CMS Overhead: WordPress Redirection Redirects
    • How WordPress Redirection Differs from .htaccess
    • WordPress Redirection Impact on Speed
• Final Thoughts & Takeaways
• Methodology Notes

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 makes a request to the server and the server responds by loading and 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 is able to 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.

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.

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. As well, 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.

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

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

Start Render Compared to Total 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.

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.

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.

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

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 with updates made to the article for clarification in 2022 and 2023. If you have questions, please contact me.