Is your WordPress website slow? Are you dreading low PageSpeed scores? If yes, then you should use Redis Full-Page Caching to supercharge your WordPress website.
In this article, we will explain what Redis Full-Page Caching is and how it improves user experience.
What Is Server-Side Page Caching?
Before we 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 grab 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.
What Are Benefits Of Using A Server-Side Cache
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 will experience a reduced load and your server CPU resource usage will decrease.
This would mean that 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 server-side page caching methods for Nginx – namely Redis Full-Page Cache and FastCGI Page Cache. Let’s see how Redis Caching works
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 the 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
Both Redis vs FastCGI Page Cache are a good solution for NGINX server-side page caching. Both of them can be installed easily in RunCloud without having to deal with Linux commands 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
Both are good choices for your WordPress website and the answer depends on your specific needs.
If you are using regular shared hosting, Redis Full-Page Cache or Nginx FastCGI Cache might not be available. In this case, the only option available is to use the WordPress cache plugins.
If you are using a dedicated server, you can 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.
Performance Benchmarks Without Caching
Let us test the capacity of our server before we enable caching so we can quantify the improvement in performance.
For this test, we use a e2-medium instance on Google Cloud and default WordPress installation using Twenty Twenty-Three WordPress Theme.
We use the free Loader.io tool for stress testing.
First Test – From 0 To 250 Users In 1 Minute
In the first test, we request the same web page from 250 different devices over the course of one minute. Without any caching, our server can successfully handle all 250 requests and manages an average response time of 140 ms.
Second Test – From 0 To 750 Users In 1 Minute
In the second test, we request the same web page from 750 different devices over the course of one minute. Without any caching, our server can successfully handle all 750 requests and manages an average response time of 408 ms. This is slightly worse than the first test but still acceptable.
Third Test – From 0 To 2000 Users In 1 Minute
In the third test, we request the same web page from 2000 different devices over the course of one minute. In this case, our server had significantly higher response times and we observed timeout error in over 50% of requests. The successful requests had an average response time of 8028 ms which is unacceptable.
Let us see how we can improve this by enabling caching.
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 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 and X-RunCloud-SRCache-Store.
The 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.
The 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 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 your web browser without using any additional tools by following these steps:
- Visit the web page that you want to test 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 traffic with the same server specifications.
First Test – From 0 To 250 Users In 1 Minute
For this test, we use Loader.io to send from 0 concurrent users and increase to 250 concurrent users within 1 minute.
Without Redis Full-Page Cache (RunCache), the average response time was 140 ms. After enabling the cache, the average response time reduces to 46 ms. This is great as our server is responding to requests nearly 3 times faster.
Second Test – From 0 To 750 Users In 1 Minute
In our second test, the average response time without Redis Full-Page Cache was 408 ms. Enabling cache lowers the response time to 43 ms. Therefore, our server can handle sudden surges in requests without degrading performance.
Third Test – From 0 To 2000 Users In 1 Minute
Without Redis Full-Page Cache, the average response time was 8028 ms and we also saw timeout error in over 50% of requests when the number of concurrent users surged to 360.
After enabling the cache, all our requests finished without error and we observed a steady response time of 41 ms. It is a clear improvement as we can handle many more concurrent requests without crashing the server.
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.
- The 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 is 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?
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 work 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.
Redis full-page caching is a game-changer for WordPress websites looking to boost their performance. With its advanced caching capabilities, Redis offers a simple and effective solution for reducing server load times and delivering a smooth user experience.
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 commands to set up Nginx cache. Sign up today and see the difference for yourself.
2 thoughts on “How To Use Redis Full-Page Caching To Speed Up WordPress”
Would RunCache work great with FlyingCDN?
Hey Chip, are you referring to this? https://flyingproxy.com/
If so, we haven’t tested it directly. That said, you can use a content delivery network with RunCache without issue. If you do bump into any issues, feel free to open a ticket and our support team will be happy to look into it.