Caching with WP Super Cache

After three years of blogging on WordPress.com, I moved back to a self-hosted WordPress.org installation so I could re-learn what I had forgotten and tinker with things that I had never tried before. I figured the first thing I’d tackle would be caching, since I hate caching. Makes sense, right? Sure . . .

Now, before I continue, I’d like to point out that I’m not a scientist. I won’t include any specific numbers for three reasons. One, I prefer to do my own investigations and I encourage you to as well. Two, Dashboard Junkie already did this. Three, I lost my numbers in a catastrophic syncing accident, but I didn’t lose my overall findings.

I hate caching. I know it’s necessary, I know it does wonderful things, but especially on a dynamic blogging platform like WordPress, I can’t stop wondering if I’m looking at a current up-to-date page or an old cached page. When I first got started with WordPress eight years ago, WordPress was not as complex as it is now, and the web was just slow in general. In short, caching was only a requirement if you were a major news site. Today, the web is fast, and WordPress is a bit more complex. Gone are the days of grabbing a coffee while your page loads. Now, folks close the browser window or simply go elsewhere when a page doesn’t load in a few seconds. If you have a public-facing site, and your server can handle the caching engine (move to another host if it can’t), you should be using a caching plugin.

I’m sure you’ve already seen the Dashboard Junkie article linked to above, showing in particular the difference between a stock WordPress site and one with a caching plugin. The differences between load time and how many requests the server can handle is astronomical. In short, a stock WordPress site will take roughly twice as long to load as a cached site, and while a stock WordPress site can handle a large amount of daily traffic, a cached site can handle a flood of visitors when you’re mentioned on the front page of a major news site. In case you’re wondering, I saw the same exact thing.

There are a lot of caching plugins to choose from, but I went with WP Super Cache, because it’s simple, and it’s developed by a fellow Automattician. After trying almost every configuration over the course of five days, I settled on the following:

• Use mod_rewrite to serve cache files: Yes, PHP is easier because you don’t have to edit .htaccess files, but PHP is already tasked with generating your site anyway, so why force it to also negotiate the cache? This is the type of thing that mod_rewrite was made for.
• Don’t cache pages for known users: Less caching means lower performance of course, but then again, I still kind of distrust caching.
• Don’t cache pages with GET parameters: Pretty much a necessity, unless you want to cache things like the panel that loads when someone shares your post via email, and other such things which really should never be cached.
• Cache rebuild: This will still serve a cache file if a new one is being generated, probably good if you’re being hammered by millions of viewers.
• Extra homepage checks: Occasionally serves a non-cached version of the homepage, which is good because sometimes caches miss things, and the homepage is where all the action happens.

It’s also worth noting that I did not choose “Compress pages so they’re served more quickly to visitors,” because Dreamhost already compresses page content on its way out to the viewer. I didn’t notice any notable performance or page size improvement when adding WP Super Cache’s compression, so I chose to spare the resources and left it off.

So, that was an awful lot of text, and thank you for reading this far! If you remember oh so long ago, I encouraged you to do your own investigations. I used Is My Blog Working? for the bulk of the data, Pingdom Website Speed Test as a secondary source of data, and Google PageSpeed Insights as an anecdotal third number which I’m sure will mean something to someone (higher numbers are better, and that’s about all that’s helpful there). Every time you make a change to the cache, clear it, wait about 15 minutes for it to catch up, then run the test three times at all three sources. If you’re on a shared server, your performance can be impacted by other sites on the server, so either average out the results or take the best from all three tries.