If you’re soccer fan like me (the World Cup is only 2 weeks away!) you probably encountered considerable frustration in the past week. This is due to FIFA ticketing system. FIFA allow fans to buy tickets through the FIFA.com website (which generally works pretty well), but in the past few weeks there have been a number of outages leading to some seriously annoyed customers. This culminated on Friday – FIFA had announced that 150 000 extra tickets would go on sale by 9 AM, but their website simply couldn’t handle the extra load and 24 hours later the problem still hadn’t been resolved.
I decided to have a look at the FIFA.com website to try and determine the cause for these problems. I obviously have no idea about the server infrastructure or failover setup, but I can examine the website itself and see if the cause is simply due to the enormous load or if it possibly could have been avoided. The following is simply ideas I would have tried to implement if I was in charge of the FIFA.com site. There is obviously no way to know whether or not this would have avoided the problems encountered.
DISCLAIMER: I don’t consider myself a web expert. If I make any glaring mistakes in my analysis, please enlighten me – I’m still learning as I go along.
To get started, let’s take a look at the World Cup Homepage. In this screenshot I actually zoomed out as far as Chrome would allow (and there’s still more content cut-off from the bottom of the page). See that red line in the middle of the picture? That’s the ‘fold’ – to see anything below that line I would need to scroll down. I would argue that there’s simply too much content on the Homepage. Since this page will be hit by every single user that’s going to the website, I would keep the content here to a minimum and perhaps move all news articles to a dedicated news section. Obviously it’s difficult to find a balance between optimization and content, but I would rather serve less content than have my entire site be unavailable for a day.
Ok, so let’s have a look at the source. First things first – the page being served has a .html extension. This is good, it means the server is serving a static page and doesn’t have to execute any code to serve the page. If you’re trying to optimize your site for high traffic volumes, you can’t really do any better than static HTML.
The HTML itself
Let’s take a look at the HTML. The first thing I looked at is the amount of whitespace – obviously whitespace is not going to make a massive difference to the speed of your site, but it’s something that’s incredibly easy to remove (there are probably 100 different ways to remove whitespace with IIS). There does appear to be relatively little whitespace in the page itself, but some of it still remains.
A few lines from the top the first real problems appear.
Lastly, the HTTP specification suggests that browser should not cache URL’s with query strings. This means that 7 of the 10 resources in this snippet will not be cached by the browser. In reality IE and FireFox do actually cache URL’s with query strings, but this is mainly due to so many sites not following the specification. (Apparently Opera and Safari don’t cache URL’s with query strings) We should always develop against the specification, not against what the browser does – this is how we got into this IE6 hell in the first place.
(The one on the right is one of the FIFA.com libraries) Again, this might be a small issue, but it all adds up and it’s so incredibly easy to fix.
The Server-Side coding
As I’ve already mentioned, I obviously have no idea about the quality of code on the server. However, we can pretty easily determine which framework is being used on the server. Take a look at the following snippet.
Yup, they’re using WebForms. I don’t want to get into an argument of WebForms vs MVC, but I really don’t think WebForms is the best solution in this case. The overhead of ViewState is simply not going to scale well enough to handle the amount of traffic you’re expecting on a site like this. You can try and throw hardware at the problem, but in the end your site is going to be slow and possibly crash completely when high traffic loads hit your site.
Http compression is something that I’ve only recently been learning about. When the browser makes the request it will add a Transport header to indicate which types of compression it understands. The server can then use one of these compression methods to compress the data it’s sending to the client. The most common HTTP compression methods are GZIP and deflate. This is something else FIFA.com did get right – if I make a request with Chrome the content is served using GZIP compression.
It’s obviously impossible to know whether or not any of the issues I mentioned here was actually responsible for the site’s downtime. In the best case scenario it might have prevented the crash, in worst case scenario it would make the site faster and reduce bandwidth costs. Keep in mind there are a whole host of other tools you can use to reduce the load on your server, these are only the main ones.