In figuring out recent problems with my blog, and running many, many iterations of WebPageTest, it became clear that my biggest performance problem was Time to First Byte — i.e., how long it took my blog to actually respond to a request for information. In general, it was taking about 20 seconds for my blog home page to load, the first 10-12 of which were that initial response.
As a result, a variety of systems simply didn’t register my blog, including Google Plus (when I tried to link to posts) and WasItUp (which you can use to monitor a website and alert you if it goes down). Worse, some of the automated systems around here (my Twitter digests, my Google Reader digests) were timing out, such that both hilarity and many, many copies of those digests ensued.
I did several things to address this, which I lay out only as some things for others to try. I’m not enough of a WordPress (let alone Apache) techie to know precisely what worked.
1. Show Me the Cache: I installed W3 Total Cache plug-in, which does all sorts of cache-y goodness. Any post you read these days about optimizing WP blogs will probably mention this one. This did a lot of good — WebPageTest gave me back loads of 2 seconds with time to First Byte of half a second … for the second retry on the site. New users (or internal utilities) weren’t getting much.
2. Reduce Clutter: WebPageTest showed me some files that were taking a while to execute, a lot of them Fun Stuff in the sidebar. I took an axe to the least important items, and cut things back a second or two.
3. Deflater Mouse: My host provides a convenient interface through CPanel to “Optimize Websites” — which means making use of mod_deflate in Apache to compress-on-the-fly files being served up (in particular “text/html text/plain text/xml text/css text/javascript application/x-javascript application/ms* application/vnd* application/postscript”). This helped things a bit (and is generally recommended on most performance sites).
4. Share the Wealth: A lot of optimization info says to push your graphic images to a Content Delivery Network like Amazon A3 and the like. Meh. Lots of work. But … the Use Google Libraries plug-in farms out loads of common javascript libraries to Google’s AJAX Libraries CDN, rather than the sites WP versions. Not only does this increase the chance of grabbing a cached copy, or making use of Google’s superior performance, but it breaks out the stacked requests to my host’s server, improving parallel performance.
5. Cram it In: I used the Delete Post Revisions plug-in to get rid of the many duplicate post revisions that WP had autosaved for me, cluttering up my blog database tables. Then I used the Optimize DB plug-in to compress the database of all that extra space. This didn’t help as much as I’d hoped (nor as much as various sites had suggested), but it’s good housekeeping anyway.
6. Farewell, My Plug-Ins: The initial negotiation between WP’s PHP code and the host’s database (MySQL, in my case) is impacted not just by what shows up on the page, but by all plug-ins that might draw on page data … even if there’s nothing they are displaying, and even if the plug-in is disabled from displaying. So I looked at my plug-ins (many), and deleted those I wasn’t using, had disabled, or could do without. One of the most significant was a second recent comments plug-in I’d played with some months back and then decided not to use, but also an RSS digest plug-in, a Google +1 button, and a couple of others were booted.
By the time I was done with all of the above (esp., ultimately, the last one), I’d dropped down to a 12-odd second load of the page, with only 3-4 seconds to the First Byte. That’s not fantastic, but it’s enough to resolve most of the performance problems / bad scores / duplicated items I was having problems with.
Knock on wood.