A Need for Speed: How I sped up my WordPress Admin and WordPress (.org) Blog

To prep for my 30 Day Blogging Challenge (#30dc), I started to give my old blog a make over. This included upgrading WordPress, my theme … and re-tagging, re-categorizing and setting featured images for all of my old posts. That was the task I was dutifully toiling away on tonight when it started taking far longer than I’d anticipated. And not because my estimate was off, but because my site’s WordPress Admin pages were taking FOREVER to load which meant long waits between every update I needed to make.

So I set out to optimize my site for speed and decided to share that as today’s #30dc post.

First, a bit about my environment:

• Basic GS hosting account on MediaTemple.
• A free Cloud Flare account that I really know very little about. I clicked through a promotion one time a long time ago when I was in my Media Temple control panel.
• WordPress 3.5.2 with wp-cache plugin active.

To start with the problem of performance on the admin side, I read somewhere that the primary culprits for slowness are plugins and themes. So I went to Plugins > Active Plugins to see the full list of plugins active. I then de-activated all of my plugins via the database. In a new browser window, I loaded my admin and browsed a bit. The interactions felt faster, though not quite as zippy as I would have liked. I then went to Plugins in this new window and went through activating each of my previously active plugins taking the time to browse a bit in-between to gauge whether or not I felt that plugin was the cause of tardiness.

NOTE: I wouldn’t typically do this in production for any client site, nor would I recommend it. However, I wasn’t worried about the random, midnight visitor seeing something ‘funky’ so proceeded to test as if I were on a development or staging or otherwise private version of the site.

While this was highly unscientific, I decided not to re-active a few plugins including Feed Statistics. This was the first one that brought my admin to a crawl when it was activated. Since I wasn’t using it anyway, I recorded the few stats I had and killed it. In addition to the perceived performance gain on the admin side, I knew that my feed URLs were my most frequented URLs so I figured this could reduce the load on my server in general. From there I chose not to reactivate plugins I knew I was no longer using anyway.

Since the public portion of the site can be accessed without a login, I proceeded to benchmark my site’s current performance at Pingdom.

• Performance Grade: 87/100
  • Leverage Browser Caching – 15/100
  • Remove query strings from static resources – 90/100
  • Specify a Vary: Accept-Encoding header – 96/100
  • Specify a cache validator – 93/100
• Requests: 64
• Load Time: 4.79s (from the Netherlands)
• Page Size: 2.8mb

Yikes. It was as bad as I thought thought, even with wp-cache enabled and running. This got me on the hunt for a better cache plugin where I then landed on W3 Total Cache. I remembered this from my time at Substance, so considered it safe to begin playing with immediately.

Knowing that it can take some trial and error to get the settings right in that they both boost performance and don’t break the site, I proceeded to test each general option out individually. For tonight, I’ve settled on the following:

• Page – enabled (Disk:Enhanced)
• Minify – disabled (when it was enabled, my theme could no longer dish up thumbnails and I wasn’t about to dive into troubleshooting that at this hour)
• Database – disabled
• Object – enabled (Disk)
• Browser – enabled
  • All options except “w3 cache header” and “disable cookies for static files” are checked
• CDN – disabled
• Reverse Proxy – disabled
• CloudFlare – enabled
• Monitoring – disabled (while I’ve heard that NewRelic may now run on MT, I didn’t have the time to go through trying to get this setup again)
• Miscellaneous – Enabled Google Page Speed dashboard & “verify rewrite rules”
• Debug – Off

As I poked around to make sure stuff worked, I also ran my site through Pingdom again and again. When I first activated W3 Total Cache – before I had any settings enabled – the performance plummeted. So that showed me that wp-cache was doing some good.

After getting all of these options set, I was still only getting a Performance Grade of 88 and load time > 2s. Pingdom was still recommending that I “Leverage Browser Caching” so I went into my Performance > Browser Cache settings and checked all the boxes I could. When I ran the Pingdom tests this time, I got a B+ if I use my old high school’s grading scale. And while I ‘d like to edge that up even higher over time, I decided tonight wasn’t that time. Sleep is far too exciting!

So for now, I’ve settled on the following report:

• Performance Grade: 93/100
  • Leverage Browser Caching – 90/100
  • Remove query strings from static resources – 61/100 (down from 90)
  • Specify a cache validator – 95/100
  • Specify a Vary: Accept-Encoding header – 100/100
• Requests: 61 (down from 64)
• Load Time: 1.22s from the Netherlands, 1.11s from Dallas
• Page Size: 2.6mb  (down from 2.8mb)

As for what’s next, I’d like to look into better optimizing my images and consolidating some of the asset requests. (That doesn’t include the rest of the interface and IA changes in the hopper.) I’d love to see it come in under 2mb and load in < 1s. I have a feeling I’ll be racing something in my dreams tonight.

Extra: Today is Day 3 of my 30 day blog challenge. Click ‘Follow’ at the bottom of the page to receive weekly updates in your inbox or follow me on Tumblr if that’s your scene.