A former college of mine told me, that he had founded “The association opposed the abandonment of PerformanceDude.com”. In order to make him happy, I thought that I would leave the wonderful world of unit testing for a moment, in the benefit of writing a performance related post :)  We’ve reached YSlow rule number 12 – Avoid redirects. I think the Yahoo documentation about the subject is a bit vague, so here’s my opinion on the subject.

Redirects are used to tell the browser, that a requested URL have been moved either permanent (http status code 301) or temporarily (http status code 302). When doing a request which returns a 301/302, the browser automatically makes a new http request, towards the URL returned by the 301/302. Being able to redirect URLs is really important if you want to change your URLs and your site is already indexed by search engines. If changing your URL scheme without returning a redirect, you basically lose your ranking in search engines like Google and all those hours spend getting link juice is wasted. In ASP.NET MVC 3 doing redirect is easy:

public ActionResult OldUrl()
{
    return RedirectPermanent("/the-new-url");
}

Notice that the above example returns a 301 (permanent redirect). If you for some reason need to return a 302, use the Redirect-method instead.

So what is my opinion on this YSlow rule? Well unless you use some sort of obscure web-framework which does a lot of magic behind the scene, there’s only one pitfall which should make you want to do something about this rule. When doing permanent redirects, ALWAYS make sure that all your internal links points to the new URL, rather than towards the old URL, letting the browser do the redirect. Implementing this anti-pattern will absolutely slow down your site!

So why do I need to think about the performance of my website, you might think. Well, maybe you don’t. If you’re making a niche website, which exports a large data set to XML, the user probably doesn’t mind if the transaction spans four or ten seconds. But chances are that you’re actually doing something where performance is an issue. Research shows that 75 percent of your visitors are less likely to return to your site if you present them with a slow experience.

Furthermore, Google announced in 2010 that site speed is now used in web search ranking (http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html). This basically means the following: if the user googles some keyword and you and your competitor has exactly the same ranking, the fastest site is presented first. This can have a huge impact on your number of visitors. Of course, the example is very simplified. A lot of factors are in play when Google decides which result to show first, and website performance is only a small percentage of the complete picture. But you probably get the idea that performance is important for Google rankings as well.

Finally, the performance is important in order to avoid your site crashing when multiple users suddenly decide to visit your site at the same time. When looking at a single page load, you could think that three seconds’ load time is acceptable by all your users. But think about the scenario where multiple users request the same resource at the same time. Most of us are on cheap hosting servers, not scaled for thousands of simultaneous requests. The result is that your load times will increase. I will talk more on tools to performance test your site with hundreds or thousands of simulated users in a later post.

Well, this is pretty much the introduction to the subject. In the next post I will get more technical. See ya!

(Proofread by inWrite)