In the world of WordPress there are many different performance optimisation best practices, and innumerable plugin based caching solutions.
But Nginx comes with FastCGI caching built in, and no plugin based solution will ever match the performance of Nginx server based static asset and page caching.
With GridPane’s highly optimised Nginx FastCGI caching, even if PHP fails your site will still be served from the cached resources until they expire. But increased speed is only half the story, the true power of Nginx FastCGI caching lies in its ability to serve your sites under incredible loads, the sorts of loads where the bottleneck becomes I/O restrictions and not server CPU/Memory resources.
FastCGI Caching is incredibly powerful, but it may be incompatible with your requirements depending on your workflow. Editing your live site with some plugins, such as Elementor, may not be possible while FastCGI Caching is enabled.
We do not recommend editing production sites in such a way, we would recommend making such edits using the staging feature and then pushing to live, however the beauty of GridPane is the freedom it offers. If your workflow does involve such a process, not to worry GridPane still has you covered with our Redis Caching solution.
1. Enable Nginx FastCGI Page Caching
Click on your site in the Active Sites panel to open the Site Customizer
Enable the FastCGI Caching Toggle
Your site will now have Nginx FastCGI Caching enabled with GridPane custom configurations.
If you visit your site and check the response headers using the site inspector you will see that caching has been enabled.
2. Enable FastCGI Cache Purging
Nginx FastCGI cache purging is one of the premium features of the Nginx Plus platform but, as is usual with the open source community, a resourceful community member has stepped into the gap and provided an invaluable asset to enable cache purging on the FOSS version of Nginx.
Most platforms have their Nginx stack compiled with the FRiCKLE ngx_cache_purge module for this, however this version of the module will only allow complete purging of a sites Cache on single user stacks where the PHP user and the Nginx user are the same.
The GridPane stack uses the Torden Fork of the ngx_cache_purge module alongside custom configurations and our custom WordPress plugin. This means the GridPane multi user server management platform has fully functioning Full Nginx Cache Purging out of the box. We are the first and currently the only platform to offer this feature out of the box, but we have also open sourced it so expect it to become standard in the near future.
Fully functioning FastCGI Cache purging requires two plugins, Nginx Helper and GridPane Nginx Cache Purger (catchy!), both of which will be auto-installed and activated on your site when you enable GridPane FastCGI Caching.
You will find them available under the Settings of your WP Admin.
2a Configure Nginx Helper Plugin for Incremental Cache Purging
This plugin allows for the incremental purging of your sites cache when you update content, such as posts, pages, comments etc. The plugin has been installed, but you need to configure it to suit your specific purge requirements.
You will need to check Enable Purge, select nginx Fastcgi cache and the default Using a GET requess to PURGE/url option.
Under Purging Conditions you should select what content you would like to trigger the purging and updating of cache.
Click Save All Changes when you have configured the options to suit your needs and now the cache will automatically purge outdated content as you update your GridPane site content.
Note – Nginx Helper Purge Entire Cache Does Not Work
Nginx Helper plugin was built for single user server stacks. The plugin functions for purging the entire cache do not work with a multi user stack like GridPane.
Purge Entire Cache Button – Does not work
Admin Bar Purge Cache – Does not work
To purge the cache at will please see below.
2b Use the GridPane Nginx Cache Purger to Purge ALL site cache
Cache purging when content updates is great, but it will not be triggered when the site updates in other ways. For example, if you have been updating your sites theme* and have new site assets, this will not trigger a cache purge.
*(We do not recommend cowboy coding – we have a fantastically powerful one-click staging solution for your development workflow)
This is when you need the ability to Purge All the cache.
The plugin is very simple and does exactly what you think. When you want to purge all cache for your site, click the big blue Purge button.
The cache purging will initiate and you will be greeted by a popup modal to let you know the plugin has done it’s job.
What if I delete the Nginx Helper and GridPane Nginx Cache Purger Plugins?
If you delete the Nginx Helper plugin, then the server will have difficulty clearing the cache on content updates, instead you will need to use the GridPane Tools to clear the cache.
You can always download and re-install the Nginx Helper plugin from the WordPress Org Repository at any time, this can be done directly from the plugins interface in wp-admin.
GridPane only automatically installs the GridPane Nginx Cache Purger plugin as an MU Plugin whenever you enable FastCGI caching. You can reinstall this plugin at anytime by toggling caching off/on or if you like you can download it from the github repo.
Part 3. How to check if your page has been cached
First, open up your website in an incognito window. Next, right click and choose “Inspect“, select the “Network” tab, and then reload the page. The result will look similar to the image below.
Click on your URL on the left hand side to open up the box on the right, then down until you see the “Response Headers” section. If our caching is active you’ll see the
Next to X-Grid-Cache you’ll see value of either:
HIT | MISS | BYPASS | STALE
HIT means the website is cached.
MISS means this page hadn’t been cached yet as it’s the first time it’s been visited since either the cache has been activated or cleared -on reload it should say HIT.
BYPASS means this page has been excluded and will never be cached.
STALE means your browsers cache has expired. This will be common with FastCGI as the cache refreshes every second by default. This still means that caching is taking place on your server.
Here is what FastCGI Page caching looks like when turned on (on activating I got a value of MISS, but now the page has loaded, on reload I have a value of HIT as shown below):
In the above image you can also see X-Grid-Cache-TTL: 1.
TTL stands for time to live, and this tells your browser how long it should cache this page for. The number next to it is the time in seconds. By default, FastCGI is set to refresh every second, so in this case we can see the number 1.
Caching won’t take place while you are logged in
When logged into your website you will see that the cache is bypassed, and in your dashboard you will see:
cache-control: private, no-store
This forces browsers and CDNs never to cache.