HomePostsSep 01, 2009

Improve WordPress Performance by 36 Percent

I was approached recently by the owner of a popular blog using WordPress software. This blog gets a lot of traffic on a regular basis but also has articles that reach the front page of Digg.com on a regular basis. For those of you not familiar with social media, this translates to very large traffic peaks. He wanted to know if there was anything he could do. As usual, Josh Can (and did) Help.

Step 1: Assess the situation

WordPress is notorious for being a big server resource hog but there is little else out there that provides the kind of flexibility and extensibility on such an easy-to-use platform. I’m sure there are debates to be had but I’m a huge fan of WordPress and that’s not likely to change anytime soon.

In this case, the WordPress core along with several essential but potentially resource-heavy plugins were causing the server to become unresponsive and, at times, crash for several minutes. This happened during short periods of intense traffic caused by the aforementioned temporary Digg.com front page position (called “the Digg effect”).

I ran a simple website optimization test and found several things that needed to be corrected:

Step 2: Plan of attack

The first thing was to address images on the site. Several images needed to be decreased in size (read: lower quality) and the images called by the stylesheet, CSS images, needed to be combined into one file called a sprite.

Since page load speed is made worse by an increasing number of server requests (the HTTP requests I mention above), I wanted to cut that amount in half or more. I would do this by concentrating on items that were loaded from the hosting server. If you load 100 objects from other servers, the page may take a while to load but the host for the page you’re viewing won’t crash. Since the primary goal was to avoid crashes, this would be an important improvement.

What happened?

Though the ideas behind the improvements were simple, there was a lot of trial and error involved. Code written by different people sometimes doesn’t play well together so there was a lot of care taken to make sure that the right syntax appeared in the combined files. The plugins themselves were actually written very well and there was rarely any problem removing the references to certain files. A few observations:

In the end…

With the changes made, we saw an improvement of around 36% (from 320 sec 56K load time to 206). The requests are sitting at 48 total (down from 90) and the site is running noticeably faster.


I made a few recommendations for managing the site going forward.

Next Steps

We’re getting as close as we can get to making the page as lightweight as possible. There are a few dynamic style sheets and JS files that could be combined if the settings never need to be changed but this might be overkill. I’d like to work out the JS minification issue if possible because we can squish 20KB out of that file.

The next big thing to tackle is the MySQL database. I found a few articles that talked about some settings that can be modified to activate caching and a few other things. I’ll try them on my server before his, though!

< Take Action >

Suggest changes on GitHub ›

Comment via:

Email › GitHub ›

Subscribe via:
RSS › Twitter › GitHub ›

< Read More >

WordPress Site Optimization

Sep 03, 2009

Friends: holding you back or helping you?

By the end of my cigarette smoking career, it had taken me about 40 tries to put those damn things down but, one day, for no good reason, I did it. Was it just one of those great miracles of life? Maybe not ...


Aug 13, 2009

Google Analytics Basics

Knowing what pages are the most popular, what keywords people are using to find you, and where people are going paint a picture about your customers.