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.

Back on WordPress.org

So, before I get too far into this post (or perhaps before I even start it), I should point out that there are essentially two recognizable types of WordPress. There’s the main one, WordPress.org, which is blogging software that you install on a hosting provider. You own it and manage it, so there are fewer restrictions, but there are more responsibilities. Then, there’s WordPress.com, a blogging service which offers you a free WordPress-powered blog with the option to purchase additional upgrades. Someone else manages it for you, so there are some restrictions, and additional features cost extra, but you don’t have to worry about anything (like features breaking, incompatibilities, downtime, etc). For a more in-depth analysis, please refer to this handy chart.

I used to blog with WordPress.org, but since joining Automattic about 3 years ago, I switched to WordPress.com, since WordPress.com is an Automattic product. It was great to get down in the trenches with our users and help to put out fires as I found them, but I found that my ability to code in PHP and JavaScript had degenerated quite a bit. There’s really no way to tweak a blog outside of CSS on WordPress.com, so no way eventually lead to no need, which lead to no want, which lead to a severe lack of practice and ultimately a loss of knowledge. Now that we have grown to 190 Automatticians, I figured there’s enough of us in the trenches on WordPress.com that I could go back to WordPress.org. Being back on WordPress.org frees me up to experiment with code again and break things on my blog, which I have been doing all weekend.

With the polite prodding of Mike Schroder over the years, I came back to my first-ever hosting provider, DreamHost. A lot has changed over the past nine years at DreamHost, all for the better. Resurrecting a nine-year-old dormant hosting account was no easy task, but Mika Epstein saved the day. It was like moving back into an old and much-loved home. Transferred a blog this size was rather rough and interrupted with frequent errors, but Michael Koenig of the WordPress.com Guided Transfer team had the magic touch and had my WordPress.com blog up and running on WordPress.org in a matter minutes. I don’t mean to sound like a commercial for one of our products, but the ability to sit back and let someone else who does this for a living (dozens of time a day) take charge of the whole situation is well worth the price.

There are a lot of handy built-in features on WordPress.com that are unfortunately left behind when you switch to WordPress.org, but it’s easy to either get them back or supplement them with something else. First, you’ll need Jetpack, which provides many of WordPress.com’s built-in features. Then, it’s just a matter of finding things to provide you with the security and reliability that WordPress.com is known for. Having talked with the folks behind Sucuri several times, I went with them for security. They’re good people, and you can trust them with the safety of your site. I also locked this down a bit more with a two-factor authentication plugin. Choosing what to use for reliable and automatic backups was an easy decision. I went with VaultPress, another Automattic product that’s well worth the price. Finally, you don’t have to worry about updates on WordPress.com, and you don’t have to on WordPress.org either, as long as you’re running the Automatic Updater plugin (from fellow Automattician Gary Pendergast).

In short, if you don’t like breaking things, stick to WordPress.com. If you want to experiment, WordPress.org is for you. DreamHost is great, and you’ll want to try Jetpack while securing everything with Sucuri, VaultPress, two-factor authentication, and the Automatic Updater plugin.