Did you know that there are 5 different places that caches can exist in any given WordPress installation? Not all installs use all levels but understanding where they are and why they’re there can help you in troubleshooting some thorny issues that caches can cause.
Caching starts before a request even gets to your server. End user browsers can cache pages, images, css files, js files and more. But your web server and WordPress configuration can control what is cached there and for how long.
Requests for data that is already cached in a users web browser is obviously the fastest response you can get to a request. This is why most WordPress installations eventually instruct the users browser to cache images, js and css files.
CDNs and PROXIES such as CloudFlare can cache pages, images, css files, js files and other static resources. A lot of data can be served from these services without the request ever touching your server.
This is internal caching done by PHP. When a PHP script is first loaded for execution, it has to be compiled down to an intermediate code format. This code can be cached so that it only has to be done once per script. Most PHP installations automatically enable this these days. You will likely never have to do anything with an OPCODE cache since they’re often cleared automatically as needed.
Querying data from the database can be expensive and time-consuming. An in-ram cache that stores the results of queries can contribute to substantial speed increases. The most common object caches for WordPress are MemCached and Redis.
One of the issues with MemCached and Redis is that they do need a plugin in order to synchronize WordPress with the cache.
WPCloud Deploy Offers options for both MemCached and Redis
When users think of caching in WordPress, this is generally what they’re thinking about. When a page is generated by WordPress, the entire thing can be stored and then served up by the web server the next time it is requested – without ever regenerating it.
This only works for pages that don’t change frequently. You certainly don’t want to be caching your cart page or your login pages or any page that might change when the user is logged.
There are a number of common methods for enabling page caching. These include:
- A plugin such as WPRocket or W3TC: Using only a plugin means that a request for a page that is cached still loads up a small portion of WordPress. (Some plugins can work with external caching services which can mitigate this shortcoming.)
- NGINX in combination with a helper plugin. Cached pages are stored on disk and requests for them never hits WordPress.
- Varnish in combination with a helper plugin. Cached pages are stored in RAM or disk and requests for them never hits WordPress.
WPCloud Deploy includes the option to turn on an NGINX based page cache.
A Hidden Sixth Layer of Caching
There is another possible caching level. Some themes and plugins add their own caching. For example many page builders create a cached CSS file that contains a combined and minified version of all the CSS on the site. A forum plugin might create a cached version of a forum page to prevent regenerating the forum list every time. So even though you might clear all the other cache levels, you can still trip over this one!
Trouble-shooting Issues With Caches Enabled
One of the first things developers of plugins and themes will ask an end user to do is to flush caches. Many times, its not clear that they mean ALL caches. Which makes it very very hard to actually nail down a problem.
So, if you are an end user trying to trouble-shoot an issue, make sure you clear all those caches. This can sometimes mean going to three or four different screens to flush caches:
- Hosting control panel
If you’re a developer trying to help a customer, you should probably create a help document to let customers know that you want them to clear all caching levels. And then make sure you walk them through exactly how to do that. It will likely save you a ton of headaches!
Here are some additional articles on Caching that might be useful:
Automatic Notification Of New Articles
Sign up to get automatic notifications of new articles. This is a different list than our standard list - you only get new articles once a week (usually on Mondays). No other emails will be sent unless you sign up for our general list as well.
Follow us on Twitter! We post a lot of cool things there first. Click the bird below!