Optimizing Boss Blueprint — Part 1
When we initially launched Boss Blueprint it was a rapid prototype that myself and my colleague had created — no optimization, no SEO, just core functionality for the sake of getting it out there quickly. A few days later the application was unexpectedly featured on WoW Insider and our traffic exploded. Fortunately, our server from (mt) held up fine and we didn’t have any outages, but we did have some mild slow downs as well as a folder of user generated images that went from 200mb to 3.5gb overnight, not to mention using a lot of unnecessary bandwidth due to the lack of optimization. In part one of this series, I’ll go into detail about some of the low-hanging-fruit that we picked for Boss Blueprint’s optimization and the excellent performance increases that resulted.
HTTP Requests and a lot of them
Since Boss Blueprint is a tool where users can create strategies for MMO games, we provide a palette of icons that are used to portray roles and direction. On the back end of this, there is a fair amount of code that creates a data object, renders the final jpeg, provides the embed code, etc. Because of the complexity, a metric fuck-ton of HTTP requests are made.
As you can see, 52 HTTP requests are made and the load time is still well over 1.5 seconds, even with the majority of the content being cached on a CDN (which we did not have upon release and still have not utilized fully).
We want the loading process of the actual work area to be as fast as possible, since the chances of someone going to the site to create a strategy are extremely high. With this, we favored loading the icon palette information on-load, rather than being requested after the user had selected a boss area and having to potentially wait before he or she saw the tools they could work with. As each icon was a separate file, over 20 of the HTTP requests above are for icons.
CSS Sprites to the Rescue
Luckily, http requests due to having a large number of images are easily reduced by creating a CSS sprite. I combined all of the palette icons into a single .png, optimized that .png, put it on the CDN, and thus obtained all the icon images with only one HTTP request.
With the same amount of data being loaded (~30kb), but 22 fewer requests being made, the site’s speed increased by about 58%. Granted, the above is all after the site has been loaded at least once by the user (thus it has been cached). Such a big difference for such a small change!
In part 2 I’ll discuss how we’re decreasing jQuery’s size by 72% and the differences in production versus development CSS files.