The Good and Bad For - Helping it Scale With Web Performance Optimization

BitCoin seems to be latest rage with wild value fluctuations. The past few days have seen a very wild roller coaster for the online currency. Most of the world's BitCoins are exchanged at, which has had some issues either with a denial of service attack or the ability to scale. Either way the site has at times been unresponsive. This has lead to a panic, causing the value of a BitCoin to drop wildly.

I have heard and read they were adding around 20,000 users a day this week with around 60,000 daily users. While those numbers may seem large to many, they are still rather small. Mt. Gox announced they were going to add more servers to solve the problem, which is a standard answer most IT operations give when they are having performance issues.

I have a lot of experience with web performance, scaling, etc under my belt and I know that most single web servers should be able to handle that traffic volume with ease. I have managed more traffic than that on a Dual Pentium 500 Mhz machine back in the day running ASP.NET WebForms. Its not just Mt. Gox, I see the same response over and over, especially in the enterprise. When I evaluate an application I find many ways to fix the issue with some simple configuration or coding changes. Sometimes it does take a complete rewrite to overcome just poor architecture and development.

First I want to point out the things Mt. Gox does right. They have a favicon, a common oversight for many web sites. They compressed their content, an easy web server configuration. They combine and minimize their JavaScripts and CSS, which I almost never see, so kudos for this. They keep the HTTP requests to a minimum, mainly due to the resource combination. Maybe a bit too many images, 23, for my liking. Some could be combined in an image sprite, but at 212 KB I will give them a break. Most sites would have downloaded over a MB just in images.

So what do they do wrong?

The biggest thing they could do is set a far future expires header. Currently they allow nothing to be cached by the browsers. This means each page request, basically anytime a user navigates to a new page in the site, they will redownload the scripts, styles and images. As I did a quick navigation around the site I see no 304 HTTP status codes. This is bad because they need to reserve this content over and over again to the same client. This consumes unnecessary bandwidth and taxes the server.

Since just about everything on their home page is static the site would load almost instantaneously after the first visit, as would just about every subsequent page. I do not have a Mt. Gox account and I own no bitcoins so I did not go into the actual trading experience. Looking at the source code they do use Web Sockets, so that tells me there is much static content that could be better served with a future expires header.

Next, they do not use a CDN. In the past this was something only the big dogs could afford. Today that is simply not true. Even I have a poor man's CDN for this blog. I setup an Amazon S3 domain a few years ago to serve my images. Today both Amazon and Azure have cheap CDN cloud services. Just doing some quick estimates for Mt. Gox I could see them spending around $5-10 a month on the Azure CDN to host their scripts, CSS and images.

This would also give them some additional benefits. It would remove that content from the main server, offloading that demand to a more scalable solution. But it would allow the static resources to be downloaded using an additional domain, meaning there are additional HTTP threads the browser will open, in this case adding speed to the site load.

Also they can be hosted on a cookieless domain. Cookies add weight to each and every resource being downloaded. This slows down the speed at which a resource can be downloaded. Since images, scripts and CSS files don't typically care if the user is being tracked it is unnecessary to host these resources on a domain needed cookies.

On to the JavaScript. While it is combined and minimized it is super large. I don't have the time to go through their code, but just a quick glance I have a feeling they are using jQuery UI without needing it. I see it referenced, but my quick passing through the site I saw nothing that warranted it. jQuery UI is very large and bulky.

Just a quick download of the latest full version of jQuery UI shows the minimized file 226 KB before compression. I used the full library because my experience tells me most developers will use it over a custom build out of fear. The site has 494 KB of uncompressed JavaScript (remember they do gzip the files, making the transfer size smaller). This tells me they have jQuery and a full set of jQuery UI included, which would probably account for about 75% of their JavaScript. My advice is determine if either are really needed, especially jQuery UI and trim the fat.

Finally they need to place their JavaScripts below their content. They have all their JavaScript files loaded in the documents HEAD. I know there are some out there that claim it does not matter anymore, that is pure hogwash. In a world where users expect a site to load and be available in less than a second everything matters. If you look at the site load you notice a blank screen, followed a few seconds later by an instantenous rendering of the page. This is because the large JavaScript has finally loaded and been evaluated.

These are suggestions based on my many years of web development and performance tuning experience. These are all front-end observations, but that is where about 80% of a web site's performance and scaling issues reside. I did not got into, nor do I have access to Mt Gox's PHP driven back end. My hope is they are using a good NoSQL option for speed as well. They are using Web Sockets, which is a very good sign they are on their way to a great modern web application.

The changes I have highlighted are easy enough to configure and setup. They could all be done within a few hours. Applying these simple adjustments to their web site could save the company thousands of dollars each month and improve the site's performance. And we all know fast sites make a lot more money!

Share This Article With Your Friends!