Don’t Assume You Need Caching On Your Website!

This article ties together a series of articles I’ve written on caching for WordPress. Ever since I migrated from shared hosting to a VPS, I’ve found myself obsessing over the necessary caching configurations I need to set up. My site is a WordPress site, and my previous web host automatically installed memcached for me. But now that I have to set up everything on my own, I needed to decide what caching method to install. After a couple of months, here are my thoughts on the matter.

There are four types of caching for WordPress sites that you need to think about when managing the software on a VPS:

1. OPcode caching
2. Object caching
3. Page caching
4. Static file caching with a reverse-proxy

1. OPcode Caching is Automatically Enabled Since PHP 5.5.0

OPCache refers to caching the compiled bytecode of PHP files so that they don’t have to be interpreted on every page load. Since these files are requested regularly, regardless of the page being loaded, it makes perfect sense to optimize this step.

Luckily, you won’t need to worry about OPcode caching since it’s automatically included with PHP versions 5.5.0 and above. You might want to fiddle with the OPcode memory allocation to ensure that there’s enough memory to handle the bytecode of all your PHP files. I think the default memory is sufficient to handle at least two WordPress sites. So change it if you need more.

2. Object Caching – Necessary Only in Certain Conditions

There are two popular solutions for Object caching:

1. Memcached
2. Redis

Here’s a tutorial I’d written to install and use memcached, and similar instructions on how to configure Redis on  VPS. Both of these solutions shine when the load on your server is high. They can handle a huge number of transactions very efficiently.

However, they won’t necessarily bring you any benefit if you have a small or medium-sized site. I’ve done extensive testing with both of these, and my site’s performance didn’t improve in the least. One reason is that I have an entire VPS’s resources at my disposal for a site that doesn’t get a ton of traffic. In these situations, adding a layer of caching might even make things worse.

So I would say not to worry too much about memcached and Redis if the load on your site is tiny. On shared hosting, the situation can vary, though you won’t have much choice in whether or not object caching is installed. It’s unlikely that your host will accommodate your request for memcached or Redis if they don’t already have it.

3. Page Caching – Blasphemy, but you Might not Need it on a VPS!

Ok, I’m probably going to get roasted for saying this, but after extensive testing on a low/medium traffic server, I can confidently say that page caching in WordPress hasn’t improved either my page load speeds or my TTFB times.

I can only assume that right now, my server is fast enough to dynamically generate the pages as it goes. It helps that I use Cloudflare full page caching, so frequently accessed pages on my site are served directly from the CDN. For the rest, my server can handle the requests easily.

On shared hosting, however, I can see that page caching helps a lot. When you don’t have an entire server’s resources available to you, it makes sense to reduce the load on the backed as much as possible. So if you’re running a VPS, do some testing with a good CDN and make sure that page caching doesn’t hurt more than it helps.

4. Static File Caching with a Reverse Proxy

This is the only one that I feel would really help even on a VPS with dedicated resources. I’d written earlier about how a reverse proxy helps with caching. Unfortunately, setting this up isn’t as easy as the other options. If you’re on cPanel, you can use the Engintron plugin. If you have a web host like NameHero however, you’re in luck because the LiteSpeed webserver has static file caching already built-in, and you don’t need a reverse proxy like NGINX.

On other control panels though, setting up NGINX or Varnish can be a serious time sink, and can require a lot of configurations, testing, and monitoring even when you know what you’re doing. For someone unfamiliar with the process, trying to figure out how it works on a production site is utterly inadvisable.

Bottom Line: Don’t Assume Anything

If there’s one thing I’ve learned in the last few months, it’s that I shouldn’t assume I need a solution just because everyone says I do. Contrary to common wisdom, Apache by itself is a pretty fast webserver if you help it along with a decent CDN. All additional caching solutions only add a new layer of complexity, whose benefits you might notice only under heavy load. But for normal websites, it might not be necessary. So test everything! And if you find that a certain caching solution isn’t bringing you the benefits you expected, get rid of it.