WordPress is a PHP application which means that every request for a page or resource requires a compilation step. This dramatically increases the response time and adds substantial load to the server. But, most pages and resources are static or do not often change. This means that once the page or resource has been compiled, it can be stored so that the next request does not require the compilation step.
The feature that implements this idea is called a “Page Cache”. Almost every WordPress host you’ve ever used provides some sort of ability to enable a page caching service. Most use an NGINIX based page cache, a REDIS page cache, a VARNISH based page cache or a proprietary page cache. But they all aim to do the same thing – store a pre-compiled WordPress page or object so that it can be served much faster.
The WPCloudDeploy Plugin uses either an NGINX based page cache or the native OpenLiteSpeed server page cache, depending on which webserver is in use.
The WPCloudDeploy Plugin uses the NGINX web server to manage a WordPress page cache. In order to do this, it requires a WordPress plugin called CACHE ENABLER (published by KEY CDN). When you enable the page cache in the WPCloudDeploy admin area, the plugin is automatically installed and enabled.
The plugin automatically generates and places pages into the page cache folder which NGINX first checks before serving up a page.
The following pages are automatically excluded from the cache:
The Cache-Enabler plugin for NGINX stores cache files in the following location:
/var/www/myblog.com/html/wp-content/cache/cache-enabler/
There are many ways to handle a page cache. A couple we have already mentioned: REDIS & VARNISH. We decided not to use any of those simply because we’re already using NGINX and NGINX can already make very efficient use a cache – if one is set up. This greatly reduces the complexity of the tech stack as well as reduces the memory in use and removes another potential point of failure where things can go wrong.
When using an OpenLiteSpeed web server, we use the built-in OpenLiteSpeed page cache along with the OpenLiteSpeed WordPress plugin.
You can access all the OpenLiteSpeed cache options from inside each website under the LiteSpeed Cache item in the WordPress wp-admin menu bar.
WordPress fires off its scheduled activities (‘cron’) only when a site has traffic. In other words, when WordPress is called to load a page or post, it also checks to see what other activities are in the scheduler that also needs to be completed. If WordPress isn’t called to load a page, scheduled activities are not run.
When a page is cached, WordPress is never called. Which means that some scheduled activities might be delayed or not get run at all.
So, if you’re using a page cache and you expect most of your site requests to be served from the cache, we recommend that you turn on the LINUX based cron process – you can do this from the CRON tab on your site.
The page cache is enabled by default on new sites. But, if for some reason it’s turned off (eg: you might have imported a site), you can turn it on as follows:
If you are using an NGINX web server you can verify that the cache is turned on by viewing the source code for a page in a browser. At the very bottom of the page code you should see something that looks like this:
<!-- Cache Enabler by KeyCDN @ 07.02.2021 00:13:37 (https html) -->
If you do not see this then either the page is not cacheable or we were unable to add a required entry to your wp-config.php file. Open your wp-config.php and verify that this entry exists:
define( 'WP_CACHE', 'true' );
It might be wrapped in a conditional such as:
if ( ! defined( 'WP_CACHE' ) ) { define( 'WP_CACHE', 'true' ); }
If you do not see it then you should add it!
There are times when you need to clear the cache so that it can be rebuilt. To do this:
Exceptions need to be added from your sites’ WordPress dashboard, not the WPCloudDeploy dashboard.
The OpenLiteSpeed Web Server cache options are only available in WPCD V 5.0.0 or later.