photo credit: Sarah Caufield

We talk about redirects in the SEO field regularly. From cleaning up 404s to preparing for a site migration, it continues to be a critical part of our website audits and site maintenance. However, when it comes to SEO, redirects are almost exclusively considered in how link equity is transferred. But are we forgetting something?

What about page load speed? We know at a bare minimum a redirect means your browser must process an additional HTTP request before rendering the page. But how long does that really take? Is it enough to matter?

In this research, I have explored a few key questions to understand how redirects affect page load time.

Methods

Methods - TL;DRMethods- Full
Using the Sandbox SEO About page as the destination for all experiments, I updated the .htaccess file with 18 different redirect combinations. I used the Waterfall tab of GTmetrix to measure the page load speed up to the phase where the About page request was completed. For each scenario, I calculated the incremental time by subtracting the recorded time from the baseline, which was established by running the About page through GTmetrix without any redirect. Finally, I ran the incremental times against a few sets of variables to measure the correlation.
Waterfall tab of GTmetrix report
Over the course of about 90 minutes 1, I updated the .htaccess file of SandboxSEO.com 18 times to test the page load speed under various redirect conditions.

I used the Waterfall tab of GTmetrix and first ran the Sandbox SEO About page (the destination used in all tests) through the tool to get a baseline. While I recorded the total page load speed each of the 19 times, I only summed everything up to the “GET http://sandboxseo.com/about-sandbox-seo” phase for the purpose of this experiment. For each scenario, I calculated the incremental time by subtracting the total “GET” time from the baseline About page “GET” time. Get it?
Waterfall tab of GTmetrix report
I did this for two reasons:

  1. There are so many other variables that affect page load speed at any given time that it would have muddied the results 2. Going this route allowed me to isolate the phase specifically affected by the redirect.
  2. If you look at the waterfall above, you’ll see this phase is a prerequisite for the next steps. Since nothing is firing in parallel, this is truly time added to the load.

Finally, I ran the incremental times against a few sets of variables through a Pearson Correlation Coefficient Calculator to determine the statistical relationship.

Sandbox SEO is a WordPress site hosted with a 10gb SiteGround plan on a NGINX server.

How much do redirect chains impact page load time?

A redirect chain is like whoever you’re going to vote for in this 2016 presidential election – it’s better than the alternative (no redirects at all), but it still sucks pretty bad.

Like I said earlier, link equity is what we usually think of with redirect chains since each additional redirect is going to dilute the authority as it transfers to its destination. But again, I wanted to look at how it affects page load time.

To set the stage, redirect chains can come in obvious and sneaky forms:

Obvious: /no-longer-exists > /former-suitable-replacement > /new-suitable-replacement
Sneaky: http://example.com/no-longer-exists > https://example.com/new-suitable-replacement > https://www.example.com/new-suitable-replacement

Global redirect rules are often not bundled or prioritized correctly to where they cause site-wide redirect chains.

Okay, here’s what I found.

Incremental Redirect Time (ms) Based # of Redirect Chains

# of Redirects Blocking DNS Lookup Connecting Sending Waiting Receiving Blocking to Receiving Total Actual Redirect Difference
0 0 0 51 0 375 0 426 0
1 0 0 51 0 439 0 490 64
2 0 0 51 0 496 0 547 121
3 0 0 51 0 548 0 599 173
4 0 0 52 0 640 0 692 266
5 0 0 67 0 694 0 761 335
10 0 0 51 0 931 0 982 556

Take a look at the first and last columns. As the number of redirects in the chain goes up, so does time. Although it’s a small sample, at a 0.9808 confidence rate 3 and the fact that it just makes sense (every additional redirect is another request that needs processed before the destination page can be recognized) makes the causal argument pretty easy.

On average, each additional redirect required an extra 63 milliseconds for the page to load.

Things that take about 60 milliseconds:

You get the picture. It’s not a lot of time. So can it really impact the bottom line? Let’s see.

An article published by Ian Laurie from Portent in 2014 says that each second shaved off of page load time results in an 8% increase in page value. Using that number along with our 63 ms average, we can assume each chain redirect has a 0.00504% negative impact on page value 4. We’ll get back to that number in a minute.

Hypothetically, let’s say your site receives 500,000 visits per year, has a 3.5% conversion rate and values each conversion at $400. Let’s also assume you have one chain redirect for each page view 5.

Chain Redirect Cost = ((500,000*0.035)*400)*0.00504

That’s $35,280 per year. And if that’s too negligible of an amount for your company to care about, by all means, I’d be glad to take that much off your hands.

Now, it’s important to know this doesn’t mean your site’s chain redirects would also require an incremental 63 milliseconds. Even in that first step of the Waterfall, there are multiple variables at play. I would recommend trying this on your own site to get a better idea of the impact 6.

How much the number of individual redirects impact page load time?

For sites that have been around a while and undergone several overhauls through the years, SEOs often face this conundrum.

  • On one hand, you would want to tie up all loose ends and redirect every old URL to its most compatible live alternative. Even if the URL has no backlinks or incoming traffic, there’s a chance people still have it bookmarked or filed away in an email and could potentially use it again. Plus, who’s to say it doesn’t carry some authoritative weight in the eyes of Google?
  • On the other hand, each redirect placed in your .htaccess file bogs everything else down a little more, including redirects that are objectively necessary. Credible sources have recommended auditing your .htaccess file and removing any old redirects for URLs that no longer matter.

With that, I wanted to run some experiments to ultimately find where that threshold should be. How many server-side redirects are too many to where it leaves a noticeable impact on page load speed?

Incremental Redirect Time (ms) Based # of Redirects in .htaccess File

# of Redirects Redirects listed before it Blocking DNS Lookup Connecting Sending Waiting Receiving Blocking to Receiving Total Actual Redirect Difference
0 0 0 0 51 0 375 0 426 n/a
1 0 0 0 51 0 439 0 490 64
1 10 0 0 51 0 417 0 468 42
1 100 0 0 79 0 502 0 581 155
1 500 0 0 51 0 437 0 488 62
1 1,000 0 0 51 0 466 0 517 91
1 6,000 0 0 60 0 532 0 592 166
1 8,000 0 0 52 0 482 0 534 108
1 10,000 0 0 63 0 487 0 550 124

Even without knowing the Pearson value is 0.4908, showing a positive but relatively weak correlation, you can already tell by looking at this chart that the data is much less conclusive. While three of the four lowest number of redirects in the .htaccess file produced the shortest times, the other of the four contained the longest.

Unfortunately, I don’t think there’s enough data here to tell us much, but until someone else or I publish a more definitive test, I’ll lean towards implementing redirects for all old URLs.

Is page load speed affected by the order a redirect is listed in an .htaccess file?

We read from top-to-bottom, left-to-right, and to the best of my knowledge most crawlers do too. So what if you had 10,000 redirects listed in your .htaccess file and the one your browser was looking for just happened to be listed last? Would having your browser first sift through 9,999 redirects add even more time to process the request?

Incremental Redirect Time (ms) Based on Order Listed in .htaccess file

# of Redirects Listed First Listed Last
100 63 155
1,000 105 91
10,000 155 124

This sample is too low to generate a Pearson calculation, and to be honest, this was a throw-in afterthought when I was finishing the tests. Still, I’d love to dive into this more or see someone else’s research on the subject. If it did in fact have an effect, we may want to consider reordering our list of redirects by how likely they are to get called upon.

Conclusion

Chain redirects don’t just leak authority and waste crawl budget, their effect on page load speed is losing money for websites 7.

The number of redirects listed in your .htaccess or web.config files may or may not be contributing to a slower page load speed. More testing is needed on the subject.

That also goes with the order a redirect is listed in the .htaccess file. At this time, it’s unclear whether the position of the redirect your browser needs within a long list of redirects impacts page load speed as well.

If you’re not sure if you have a redirect problem and don’t know where to start, while it’s a few years old, I recommend reading through Dan Shure’s post on checking for redirect chains on your site.


  1. With so many fluctuating variables that impact page load speed, I wanted to run these tests in succession.

  2. Seriously, run the exact same URL multiple times through GTmetrix and you may be surprised how varied the results are.

  3. 1.0 is a perfect correlation. Anything over 0.5 is considered a strong correlation.

  4. (63/1000)*0.08)

  5. This isn’t that unordinary. For instance, many sites upgrade to https and forget to redirect http > https as well as update their internal links.

  6. If you can’t test, run GTmetrix for your page with no redirect and multiply the destination page “GET” phase by 14.8% ( 63 ms/426 ms), which is my incremental redirect time divided by my baseline time. I would imagine the ratios are fairly similar between sites.

  7. not to mention the fact that page load time is a ranking factor