We are excited to release the Redis Full-Page Cache feature as further enhancements to our RunCache feature to boost WordPress performance using a server-side caching system.
In the RunCloud panel, you will now find two NGINX page caching methods while installing RunCloud Hub, Redis Full-Page Cache and FastCGI Page Cache.
Redis Full-Page Caching enables your server to serve the full-page cache from in-memory store using Redis.
In this post, we will enlighten everyone from beginner to expert on this topic, and make Redis Full-Page Cache as one of your top favorite features in RunCloud.
Table Of Contents
- What Is Server-Side Page Caching?
- What Is Redis Full-Page Caching?
- Redis Full-Page Cache vs Nginx FastCGI Cache
- Server-side Page Caching vs WordPress Caching Plugins
- Who Needs Server-Side Page Caching For WordPress?
- How To Install Redis Full-Page Cache Using RunCloud Hub
- How To Check If Redis Full-Page Cache Works
- Performance Benchmark: Handling More Traffics
- Exploring RunCache Features
- Is It Compatible With Popular WordPress Cache / Optimization Plugins?
What Is Server-Side Page Caching?
Before we focus to talk about Redis Full-Page Cache, let’s talk about how your website works.
- When a user visits your WordPress page, the web browser sends an HTTP/HTTPS request to Nginx.
- Nginx passes the request to PHP-FPM, and Nginx will catch any PHP codes when trying to grabbing the page.
- PHP-FPM processes the page and runs through the MariaDB/MySQL database query to retrieve the page.
- PHP-FPM sends the generated “static” HTML page back to Nginx.
- Nginx sends the generated HTML page to the web browser for the user.
When using server-side page caching, the Nginx module will be in between Nginx and PHP-FPM and it is able to generate a cached HTML page from PHP-FPM.
When another user visits the same WordPress page, your website will not perform the same PHP and database requests again because the page is already cached and served by Nginx directly.
As a result, your server response time will be much faster after the initial load.
Your PHP-FPM and MariaDB/MySQL load will be reduced.
Your server CPU resource usage will be lower.
And finally, your server can handle more traffic with the same server specifications when using server-side page caching, ultimately allowing you to keep a more affordable server without having to scale any further.
RunCloud provides two different Nginx server-side page caching methods
- Redis Full-Page Cache
- FastCGI Page Cache
What Is Redis Full-Page Caching?
Redis, which stands for Remote Dictionary Server, is a fast and open-source, in-memory data structure store used as a database, cache, and message broker.
In contrast to databases that store data on disk, all Redis data resides in memory, avoids seek time delays, and can access data super fast in microseconds.
Usually, Redis is used to cache database query results and used to enable object caching, not page caching.
Using Nginx SRCache module, we can use Redis to serve a different purpose, to provide subrequest-based page caching as an alternative to Nginx FastCGI Cache.
Redis Full-Page Cache vs Nginx FastCGI Cache
Which one is better?
Both Redis vs FastCGI Page Cache is the best NGINX server-side page caching that can be installed easily in RunCloud without having to deal with Linux command to setup, no complex process required.
You should try it on your WordPress site to find the one which works best for your current setup. You can even switch between Redis and FastCGI page cache in one-click.
Server-side Page Caching vs WordPress Caching Plugins
Many WordPress users ask the same question, which one is better?
Actually, both are good for your WordPress website.
When using regular shared hosting, either Redis Full-Page Cache or Nginx FastCGI Cache is not available, and the only option available is the WordPress cache plugin.
You will need a VPS / Dedicated server to allow you to optimize your WordPress site using server-side page caching.
With proper setup, server-side page caching can perform better than any WordPress cache plugin.
Who Needs Server-Side Page Caching For WordPress?
All WordPress pages can gain huge benefits when using RunCache server-side page caching.
For blogs, magazines, news, company profile websites, and all types of “static” WordPress sites, all WordPress pages can be fully cached and served faster, excluding WordPress admin pages, which are not cached for obvious reasons.
For e-commerce, membership, forum, and all types of “dynamic” WordPress sites, most WordPress pages can be fully cached and served faster, except for some pages that should stay dynamic.
For example, in the case of WooCommerce, the homepage, shop page, and single product page can be fully cached, but cart, checkout, and my account pages should be excluded. For these dynamic pages, you can use Redis Object Cache to reduce your MySQL database load and make your dynamic pages load faster, but you do not want to cache these pages fully as the latest changes will not be seen.
How To Install Redis Full-Page Cache Using RunCloud Hub
RunCloud Hub is a hub for all RunCloud plugins for WordPress. It is not only for server-side page caching but also Redis Object Cache and Server Health & Transfer Stats monitoring directly from your WordPress dashboard.
If you want to use server-side page caching, either Redis Full-Page Cache or Nginx FastCGI Cache to speed up your WordPress website, then RunCloud Hub is the perfect choice for you.
You can simply go to the RunCloud Hub menu under your web application in the RunCloud panel, choose the Nginx page caching method, and click the Install RunCloud Hub button.
Once you have installed the RunCloud Hub plugin, Redis Full-Page Cache (RunCache) is automatically installed and enabled in your WordPress website, no complex process is required.
How To Check If Redis Full-Page Cache Works
When using any cache WordPress plugin, usually the plugin adds a footprint at the of your web page source code to make it easy for you to check check if your WordPress page has been cached or not.
Redis Full-Page Cache (RunCache) works on the server-side, which means there is no footprint on your web page, you need to check the headers of your website to see these possible values of
X-RunCloud-SRCache-Fetch header returns the status of the “fetch” phase for Redis Full-Page Cache. Three values are possible.
- HIT : Page is cached and served from the cache.
- MISS : Page is served dynamically from the server, not from the cache. The response might then have been cached. Refreshing this page again should change the header from MISS to HIT or BYPASS.
- BYPASS : Page is served dynamically from the server, not from the cache. It is excluded from the cache, for example, WordPress dashboard admin pages or WooCommerce cart/checkout pages.
X-RunCloud-SRCache-Store header returns the status of the “store” phase for Redis Full-Page Cache. Two values are possible.
- STORE : An Nginx subrequest is issued to save the HTML output of the page into Redis.
- BYPASS : An Nginx subrequest is not issued because either it has been saved to Redis or it is excluded.
To make it easier for you to understand, usually, we can see 3 common pairs of these headers, for example:
“MISS” Fetch Status and “STORE” Store Status
This is when you visit a page for the first time where this page is served dynamically from the server and the output of this page will be saved to the Redis.
“HIT” Fetch Status and “BYPASS” Store Status
This is when you visit a page where the cache version is available in the Redis and served directly from the Redis cache.
“BYPASS” Fetch Status and “BYPASS” Store Status
This is when you visit a page that is excluded from the Redis cache.
To check these headers, you can use some tools, for example:
Check HTTP Headers With GTMetrix
Gtmetrix is not only for testing your performance score, you can also use it to check the response header using the Waterfall feature. You can check the response header of your tested page under the Waterfall tab to see if this page is served by Redis Full-Page Cache (RunCache).
Check HTTP Headers With Google Chrome
You can also view the response HTTP headers in Google Chrome by following these steps:
- In Chrome, visit your web page and open Web Developer Tools by pressing F12 or right-click and selecting Inspect.
- When opened, click and select the “Network” tab.
- Refresh the page to get fresh page data.
- Select the top HTTP request on the left panel and observe HTTP headers on the right panel.
Performance Benchmark: Handling More Traffics
By eliminating PHP-FPM and MariaDB/MySQL when serving your WordPress page from Redis Full-Page Cache, the huge benefit is your server can handle more traffics with the same server specifications.
For this test, we use Amazon Lightsail 1GB RAM ($5) and default WordPress installation using Twenty Twenty WordPress Theme.
We use the free Loader.io tool for stress testing.
First Test – from 0 to 100 users in 1 minute
For this test, we use Loader.io to send from 0 concurrent users and increase to 100 concurrent users within 1 minute.
Without Redis Full-Page Cache (RunCache), the average response time is 1174 ms. You can see that as concurrent users increase, the response time increase also. Your website will be slow when you have more visitors.
With Redis Full-Page Cache (RunCache), the average response time becomes lower, 24 ms, increasing visitors from 0 to 100 users doesn’t affect too much on the response time.
Second Test – from 0 to 200 users in 1 minute
Without Redis Full-Page Cache (RunCache), the average response time is 2312 ms.
With Redis Full-Page Cache (RunCache), the average response time becomes lower, 51 ms.
Third Test – from 0 to 500 users in 1 minute
Without Redis Full-Page Cache (RunCache), the average response time is 5545 ms. And we also 8% timeout when there are 475 concurrent users.
With Redis Full-Page Cache (RunCache), the average response time becomes lower, 139 ms.
Fourth Test – from 0 to 2000 users in 1 minute
Now, let’s try to give 2000 concurrent users in 1 minute. Redis Full-Page Cache (RunCache) on Amazon Ligtsail 1GB RAM $5/month VPS still can handle it with 827 ms average response time.
Exploring RunCache Features
Using the RunCloud Hub WordPress plugin, you will have more controls on how RunCache works on your WordPress website.
Purger settings allow you to have more control when the cache is cleared, for example:
- Automatically clean cache of homepage when post is edited or has a new post.
- Automatically clean cache of homepage when post removed.
- Automatically clean cache of post/page/CPT when published.
- Automatically clean cache of post/page/CPT when comment approved and published.
- Automatically clean cache of post/page/CPT when comment removed.
RunCache Rules / Exclusion
Rules settings allow you to control Cache Exclusion.
Exclude URL Path option allows you to exclude cache based on matching URL Path. This is very useful when you have dynamic pages that should not be cached in your website.
For example, in WooCommerce, you have the Cart, Checkout, and My Account page that must never be cached. For WooCommerce users, no action needed, these pages have been added by default.
Exclude Cookie option allows you to exclude cache based on matching Cookie name.
Exclude Browser option allows you to exclude cache based on matching Browser User-Agent.
Exclude Visitor IP option allows you to exclude cache based on matching Visitor IP Address.
RunCache also has dedicated settings for query strings, because query strings will not cache by default.
Allow Cache Query String option makes it possible for you to allow cache based on matching query string, for example, UTM parameters (utm_source, utm_medium, utm_campaign), fbclid, gclid, etc.
Exclude Cache Query String option allows you to exclude cache based on matching Query string.
Preload settings allow you to generate caches of your pages without having to wait for a user to visit your pages. Normally, the cache is generated after a user visits a page.
You have the options to:
- Preload caches automatically when any purge action was triggered.
- Preload caches automatically based on schedule time (day/week/month).
- Preload caches manually by clicking the “Run Cache Preload” link.
If you have a big number of posts/pages/products in your WordPress sites, the cache preload process sometimes can consume your server CPU resources. It is better to run a cache preload manually for this case.
Is It Compatible With Popular WordPress Cache / Optimization Plugins?
Short answer, YES!
The important thing to understand, Redis Full-Page Cache (RunCache) works on the server level and popular WordPress cache/optimization plugins work on the WordPress/application level.
They are in different spaces and it should be compatible.
If needed, you can combine it with your favorite optimization plugin, for example:
Redis Full-Page Cache and Autoptimize Plugin
In fact, Autoptimize and RunCache are a perfect combination to optimize your WordPress site.
Please read the detailed guide here, How To Use Autoptimize WordPress Plugin To Optimize Your Sites.
Redis Full-Page Cache and WP Rocket Plugin
When using WP Rocket plugin, combined with Redis Full-Page Cache (RunCache), WP Rocket page caching feature is automatically disabled by RunCloud Hub.
It means Redis Full-Page Cache will handle the page caching, and you still can use other WP Rocket optimization features.
In RunCloud, we provide you with full control over your server. That is why we do not apply any server-side caching mechanisms automatically to your server.
If you want to apply server-side caching to one of your web applications within your server, then RunCache (RunCloud Hub) is your answer.
RunCache allows you to utilize either Nginx FastCGI Cache or Redis Full-Page Cache to speed up your WordPress performance without having to deal with Linux command to setup Nginx cache.
All paid plan users (Basic, Pro, Business) can enjoy the full functionality of this Redis Full-Page Cache feature.
We are very excited to bring this feature to RunCloud. Never ever hesitate to suggest new features that you want to see, and we will make it happen.