In January of 2011, the third full month after putting this site online, there were roughly 450,000 page views requiring 27GB of bandwidth (i.e., mostly data provided by the server to users). In April of 2011, there were also 450,000 page views, but only 14GB of bandwidth. That’s a dramatic difference: half the bandwidth for virtually the same amount of traffic! This wasn’t a goal of mine (my hosting plan allows for up to 1TB of bandwidth per month), but happens to be a great side benefit of three steps I took, primarily with the aim of improving the site’s performance (i.e., how quickly pages load for visitors). Here’s the full scoop…
In the Fall of 2010, I was finally able to purchase my name as a domain, allowing me to switch from using my company’s domain name (www.DMCInsights.com) to this domain for all my work stuff (the company is just me and no one cares about the company). In the process, I went from a custom site to using a WordPress-based one. The custom site primarily used PHP to handle the templates, but it also pulled some content, such as book errors, out of a database, and ran the newsletter system. Part of the justification for moving to WordPress was that I had previously (and finally) created a blog on a subdomain of my company’s site, and consequently the blog had the most frequent updates (by far). The “main” pages of my old site were not being updated with any frequency, making the site erroneously seem inactive, so the blog needed to be moved to the forefront. Another part of the justification was that by using WordPress, I would easily get a search engine for my entire site, something I had never gotten around to adding to the old site. In the process of switching, I also created a new template, based upon the Carrington Theme. The transition from the old site to this new one wasn’t perfect, but overall I think it went well enough. I’ve had to spend some time putting out little fires (there was an issue with redirects and I have to occasionally debug conflicts between the Flash widget and the navigation menus), but just by creating the new site, I was able to revisit and update all of the site’s content, which is something I should have done long ago.
The downside to using WordPress, or any Content Management System (CMS), is that general-purpose software is always going to be less efficient than a custom solution. WordPress, while being an excellent product, simply cannot be both flexible and optimal (from a performance standpoint). Once you start using plug-ins, performance is hindered even more so. After putting the new site online, I started analyzing its performance, using YSlow! (which I’ve written about previously). YSlow! makes specific recommendations for improving a site’s performance, which is a great way to get started. Once you know what you’re doing, however, or are looking at the site on a micro level, you’ll start paying more attention to what YSlow! reports as the resources being loaded: the number and size of requests being made. What I saw was a lot more CSS, JavaScript, and media being loaded than I had expected. I had specifically chosen a theme that was relatively simple in terms of images and yet… And then there are all those CSS files and JavaScript libraries! Ugh. The problem, in hindsight, was obvious: many of the plug-ins added their own CSS, images, and JavaScript to each page. The first, and most important, step for improving a site’s performance is common sense: Limit how much stuff the visitor has to download.
There are two ways of limiting the amount of content to be downloaded. First, you can outright eliminate the need. This is not always possible, but should be the first goal. With a standard site, you may be able to cut the amount of media used. You should also remove outdated references to CSS, JavaScript, and media once those assets are no longer needed. For example, after altering the settings for this theme, there were many resources that no longer needed to be loaded and you might encounter the same thing after a major redesign. Second, you can combine downloaded content together: multiple CSS files can be turned into one; multiple JavaScript files into one; and multiple images into a couple of CSS sprites. This isn’t always possible, or appropriate, but is worth investigating. With images, you can also use Yahoo!’s Smush.it tool to make images as small as possible. I was able to reduce the combined size of all the images by about 15% or more using it (your results may be better as this site uses few and small images). CSS and JavaScript files can be minimized to shrink their sizes down.
With this WordPress site in particular, restricting the number of images, CSS files, and JavaScript includes required actively tweaking, and sometimes replacing, the plug-ins in use. Some of the smartest plug-ins allow you to disable their automatic CSS and JavaScript inclusion, leaving it to you to manually add that content to the theme’s primary files instead. If you’re also using WordPress, take a moment, or a day, to really investigate what your plug-ins are doing. In some cases I was able to outright disable the plug-in and hardwire its functionality to my theme.
The second change I made to the site (in February), which had a huge impact on the site’s performance and its bandwidth was embracing a Content Delivery Network (CDN), specifically Amazon’s Cloudfront. Most of the site’s supporting resources—CSS, JavaScript, and images—are now being provided by Amazon’s worldwide network. The original goal for using the CDN was to provide content to visitors from servers closer to their geographic location, but this also means that a ton of served data is not being provided by my server. For the month of April, that amounted to approximately 8GB! When I first learned about CDNs, I assumed they were only for huge sites that could afford the expense, but Amazon’s Cloudfront has definitely changed that equation. My cost for the month of April: $1.77 (US). As I’ve written about separately, for the first year, the cost of Amazon’s Simple Storage Service (S3) is free, so next year this total cost will increase, but, still, it will be very cheap for what I’m getting.
If you run the numbers, in April I used 13GB less bandwidth than in January. Assuming that the incoming bandwidth is inconsequential, after deducting the 8GB served by Amazon’s Cloudfront, there’s still another 5GB of data that’s no longer being provided by my server. Much of that was by eliminating the amount of data to be downloaded (i.e., step one), but I suspect another key change, made in March, was the switch to new forum software. Again, the intent here was not to change the bandwidth, or really even to improve the performance, but rather upgrade an important and sorely outdated aspect of my site. The forum probably gets as much traffic as the main site and I strongly suspect that the new forum software is optimized more thoroughly than the open-source alternative I had previously been using.
As I said, I’m not even closing to hitting the bandwidth limitations on my hosting account, but less bandwidth used (for the same amount of traffic) is a good thing. Not only does it imply better performance for my site’s visitors, but it also means that it’ll be that much longer before I need to spend the extra money on bigger or more servers. But perhaps the more important lesson I learned is how useful it is to do thorough examinations of your Web sites, especially after the’ve been up for a while. A Web site is a dynamic thing that needs to be maintained and updated, not posted once and forgotten.
