I was recently working on a project to bring down the page load times for a client’s website. The main functions of the site are to sell a handful of products, as well as bring in traffic for several popular keywords. The site also gets pretty good Adsense revenue, as well as making money from several affiliate links on pages. He has a lot of traffic, but sales and ads don’t reflect what he should be getting for the amount of visitors. I attribute a lot of this to the page load time. Every web marketer under the sun will tell you that faster page loads almost always means better results, whatever it is you’re hoping to achieve. There is no calculated benefit to somebody waiting for your page to load. The risk that they close the tab or click “back” while they are waiting is just too high.

Site Analysis

This website is built in WordPress, has about 400 posts and 11,000 comments (yeah, a lot of comments!). On average the site gets about 5,000-7,000 visits per day, and the page load times (according to Google Analytics) were around 20-25 seconds. Terrible! Tests on GTmetrix and Pingdom (while both slightly lower than Google Analytics) confirmed the page load times were really high (around 19 seconds in many cases). Something needed to be done. My goal was to bring page load times to around the 5-second mark. The client didn’t want to spend much money on optimization, so that was also something to consider.

Step 1: Caching

WP Super Cache is installed on the site, and has a few settings applied to at least serve cached pages to the visitors. This didn’t help much with page load time, but it did mean the server wasn’t quite so busy producing fresh pages every time a visitor landed on the site. Personally I use W3 Total Cache on my site, but I’ve also had good experiences with WP Super Cache. Check out this post on how to correctly setup WP Super Cache.

Step 2: CDN (Content Delivery Network)

The web host of this website is in Malaysia. I had a sneaking suspicion that with all the traffic the site gets, it was putting serious strain on the shared server, and taking unnecessary amounts of time to send files across the Pacific Ocean to the main demographic – the United States. So my first approach was to setup a CDN for the site. With a CDN, your files are copied (no effort required on your part) to the CDN’s servers and distributed to the visitor from the location closest to them. Not only that, but because the servers are faster, closer, and more optimized for distribution, it means all of your files can be loaded at the same time, instead of a typical sequential load. Keep in mind, this applies for CSS files, images, and javascript on your server. The CDN does not claim to cache and deliver files you are referencing from 3rd party sites (ie, Facebook, Google Plus). If you want to try it out, check out MaxCDN. They’re great.

CDN Results

The CDN we chose for this was MaxCDN. For the 1st Terabyte it was $40, and with a coupon code for 25% off it was even cheaper. Setup was quite simple. Once it was setup, back to the page speed tests.

Before the CDN: 75% of “time spent per domain” was on the website. Meaning that for every 10 seconds the page took to load, 7.5 seconds of that time was being spent loading things from the website’s own server.

After the CDN: 6.45% of “time spent per domain” was on the website. So in plain English, this means that since we “outsourced” all of the big files off the server, that for every 10 seconds loading the page, less than a second was spent on the domain’s actual servers. This is huge!

Now, that being said, I didn’t notice a huge drop in page load speed. I was puzzled by this, but still happy with the results of the CDN. At least we narrowed down that now almost no speed was being lost by waiting for the Malaysian servers to respond. On to the next step!

Step 3: Trimming down server requests

The average page on this website had well over 150 server requests. This means every time the page was loaded, the browser had to go grab 150 different files from dozens of different domains. We needed to trim this down. We had already slimmed the site’s own server requests by offloading them to a CDN, but there were a lot left to deal with. A lot of these requests were because of WordPress plugins. We used P3 Plugin Profiler to cut time spent on loading plugins in half! Plugin bloat is one of the leading causes of WordPress heart attacks, don’t let it happen to you!

Step 4: Social

When an average blog post on the site is loaded, it loads the following:

• sidebar – Facebook Like box (with 12 faces showing)
• sidebar – Twitter feed (latest 10 tweets)
• sidebar – Feedburner count
• post – +1 button
• post – Facebook “Like” button
• post – Facebook Like box (with 12 faces showing)
• theme – floating +1 button
• theme – floating Like button

I’m sure I’m missing something, but you can see there are a lot of calls involved there. For Facebook alone the browser was making 48 requests. So Facebook accounted for over 32% of “time spent per domain”. For every 10 seconds spent on the page, 3 seconds were spent downloading stuff from Facebook! Now, one thing we need to think about is value of these things. This site depended heavily on social networks to get the word out about their products and bring in traffic. The Facebook page alone had close to 4,000 Likes, not to mention all the Twitter followers, Feedburner subscribers, and +1′s. So we couldn’t just take all of these items off. We needed to be deliberate and thoughtful when it came to analyzing the value of these social requests. In the end we left most of the social features enabled, but did remove a floating social icon box. That lessened the requests by a few. Can’t hurt!

Step 5: Intense Debate and WordPress commenting

Found it! It turns out that comments actually ended up being one of the biggest strains on the website.

The site was very popular, and received sometimes hundreds of comments per post. In fact on one of the site’s most popular products there were over 500 comments. The comments were great credibility to the site and product, so removing them outright would be a bad move. So instead of removing, we tried a few different things. First, we disabled IntenseDebate and just tried out WordPress’ default comment styling. This proved…pointless. It meant a few less calls to external sources, but in the end it didn’t save any time.

HOWEVER, I discovered something critical during this part of the process. And it has to do with the link between WordPress and IntenseDebate. The IntenseDebate settings were such that when WordPress loads the comments into the page, IntenseDebate takes them and formats and “pages” them (10 per page in this case). What I didn’t realize until I disabled IntenseDebate was that WordPress did not have its own limit set on “comments per page”. AHA!! So, this one product page was literally loading 500 comments, and then IntenseDebate was just reformatting and paging them to show 10 at a time. So I went to Settings > Discussion and set WordPress to split comments into pages with 10 comments per page. Save, refresh, tada! Now WordPress gave only the 10 comments to IntenseDebate that it was looking for. Instant boost in page speed! This may have been the single biggest drag on the system!

Step 6: Comments and Gravatars

A big reason there were so many requests the browser was making was also largely because of the amount of gravatars used in comments. For these tests we disabled gravatars both in IntenseDebate AND in WordPress. And when a gravatar was unavailable we used the “Blank” avatar. I think enabling the gravatars should work ok, as I’ve heard of a few plugins out there that will cache the gravatars on your site. These images would then in turn be cached by the CDN, therefore speeding everything up once again. But that is a test for another time.

Results: Comparing page load time using Pingdom

Here are my stats on the page load times of 3 pages (home page, the most popular post, and a random post) both before and after the above-mentioned changes. Pingdom allows you to compare three different cities (New York, Dallas, and Amsterdam). So the numbers below are averaged from all 3 city results.

HOME
Before: 151 requests 1.13MB 19.9 seconds
After: 135 requests 0.91MB 4.06 seconds

15.8 seconds saved (page loads 79% faster)

POPULAR POST
Before: 196 requests 1.30MB 11.51 seconds
After: 173 requests 0.97MB 4.8 seconds

6.71 seconds saved (page loads 58% faster)

RANDOM POST
Before: 200 requests 1.47MB 9.73 seconds
After: 182 requests 1.1MB 6.58 seconds

3.15 seconds saved (page loads 32% faster)

Google Analytics Page Speed

And finally, according to Google Analytics these changes have netted a 6.09 second sitewide average savings. That means site-wide pages are loading 27.9% faster than before.

So I didn’t necessarily reach my goal of 5 seconds per page, but we got pretty close. And when you factor out all of the non-targeted countries (client mostly wanted US clients), it was an acceptable change.

I’ve seen a lot of blog posts talking about CDNs, server requests, social plugins, etc. They all talk about how you’ll boost your site load speed by incredible amounts. I’m not really sure I buy it. If you’re dealing with a really bland site that has very well performing plugins, this may be true. But web design is messy. Once you hand a site over to a client, they may get their grubby little hands (meant in the most respectful way possible!) all over it and start doing things that seem to be good ideas. So, as I said, analyzing and optimizing your page load time is a sticky process. It takes weeks, months even to get it right. And then go and add some random plugin, and you have to start pieces of it all over again! But personally, it’s a challenge I love.

Have any tips on optimizing WordPress for faster page load time? Let me know, every site is a work in progress!

Side note: read this on how to set your page load sample in Google Analtyics.