Refund Policy

Caching is the backbone of website speed and performance. It’s critical to your WordPress site’s success. Even if your site is hosted on a hefty server, it’ll come to a crawl if you don’t have any caching enabled. Serving websites to tens of thousands of users per day is possible only because of smart caching techniques.

In this article, I’ll pit two distinct WordPress page caching solutions against one another. While NGINX FastCGI Cache is a tried and tested page caching veteran, Redis Full-Page Cache is relatively obscure.

Who will come out on top and who will crumble under the load first? As you’ll soon find out, they both have their pros and cons, but there’s only one winner.

Buckle up. Let’s zoom in!

WordPress Caching 101

WordPress requires many moving parts to work. Every time a user requests a page from a WordPress site, the request is first parsed by the server. If the server cannot serve the requested page readily, it’ll process the relevant PHP scripts and assemble the page dynamically. Sometimes, this also involves querying the database to gather additional data.

As a general rule, the longer the request has to travel, the slower the server’s response. If there are a lot of concurrent users, the server can freeze trying to process all the parallel requests. 

Caching helps to speed up server response by storing and delivering previously processed requests. A server can deploy many caching layers to store distinct types of data.

For PHP and database based applications such as WordPress, there are four major types of server-side caching solutions: Object Caching, Page Caching, Opcode Caching, and CDN Caching. You can read more about all of them in WP Rocket’s in-depth article on object caching.

This article focuses on comparing page caching solutions, but I suggest you get familiar with the basics of object caching too.  

Setting Up the Test Site and Server

I’ll use a $10 standard droplet from DigitalOcean to conduct the tests. With a decent mix of memory and compute resources, it’s a perfect server to test the WordPress site. The droplet configuration includes 2 GB RAM, 1 CPU, 50 GB SSD Storage, and 2 TB transfer.

I’ve installed the test WordPress site on a Debian-based LEMP stack (Linux, NGINX, MariaDB and PHP 7.3). To stress the test site, I’ve customized it to include a decent mix of static and dynamic elements using WooCommerce and Elementor.

I tested the base site with the GTmetrix website speed testing tool. As you can see from its test report, it’s not yet optimized for performance.

Stress Testing the Base Site with No Cache Enabled

I’ll use a free performance testing tool called loader.io to stress test the website. Their free tier allows you to test two URLs of any website with up to 10000 concurrent clients for a minute. That’s more than enough for our use case. 

Note: If you’re wondering about the domain name, it’s an unused personal domain. It’s essential to have the site hosted on an actual domain to install an SSL certificate from a signing authority such as Let’s Encrypt. With an SSL certificate installed, the site has to perform an HTTPS handshake for every unique client request. This mimics real-world usage better during the stress test.

You can check the test parameters inside the orange box on the left side. Note the 0 to 200 clients over 1 min test parameter. This means that loader.io will stress test the website by slowly increasing the number of active clients from 0 to 100 over a 1 minute period. 

In the graph shown, the green line represents the number of concurrent clients and the blue line represents the average server response time. You can see that the response time creeps upwards as the number of clients increases. 

Loader.io aborted the test after 36 seconds as more than 50% of the requests weren’t successful (a timeout or an HTTP 400/500 error response). Also, the 17.33 seconds average response time doesn’t bode well for the user experience either.

Checking the Details tab will give you a better understanding of when the server timeouts start. You can see that it starts at the 25-second mark.  

I ran the test again, this time limiting the number of concurrent clients to 100. The base site struggled to perform even under this minimal load.

The test ran for a full minute this time around, but the average server response time is still unacceptable. Every active user stresses the server more, which makes it respond slowly to all the other users. The server timeouts still persist.

From the above graph you will notice that server timeouts start to occur at the 38 second mark in the test.

Now you have a fair idea of how the base site performs when there are 100 and 200 active clients. It’s time to perform the same tests with Redis Page Cache or NGINX FastCGI Cache enabled on the server.

What is Redis Full-Page Cache?

Redis (Remote Dictionary Server) is an extremely fast in-memory data store for a database, cache, proxy, and more. 

Since Redis stores its data in-memory, as opposed to traditional databases that store data on physical disks or SSDs, Redis can seek and deliver data super fast. 

As in-memory storage is costlier to scale on a web server, Redis is ideal for caching smaller files such as database query results and persistent sessions. Thus, Redis is typically used to enable object caching and not page caching.

The smart folks over at Pressjitsu adapted the unique features of the Redis server and implemented a Redis-backed page caching solution for WordPress. It uses Redis’ maxmemory #mb and maxmemory-policy allkeys-lru directives to ensure that the server utilizes its limited volatile memory efficiently by removing older cached pages to make room for fresh ones.

Redis Page Cache stores and serves the full-page cache from in-memory store, just like how Redis Object Cache works. Technically, this should make it a highly fast cache.  

How to Enable Redis Page Cache

The documentation to enable the Redis Page Cache plugin is a bit inconsistent. After some trial and error, I got it working on my setup. Here are the steps I followed:

1. Before installing the plugin, make sure you have the Redis server installed and running on your web server. If you’re using Debian/Ubuntu, here’s the command to install it via terminal:

sudo apt-get install redis-server

I highly recommend you to follow Digital Ocean’s tutorial on installing and securing Redis on your Linux distro. If you have any other variant of Linux, they also have separate tutorials catering to almost every major Linux distro. 

 2. Once you’ve installed and configured Redis on your web server, you need to install the PhpRedis extension on your server. It provides an API for PHP to communicate with the Redis key-value store.

sudo apt-get install php-redis

Restart your PHP server after installing the PhpRedis extension. You can do it with the following command:

sudo service php7.3-fpm restart

Note: My web server runs PHP 7.3 version. You need to use a command corresponding to your web server’s PHP version.

3. You need to ensure that the Redis server has enough memory allocated to store the page caches. Redis Page Cache recommends that you allocate at least 16 MB just for page caching. You can do this by adding the following line to your redis.conf file: 

maxmemory 256mb

I’ve allocated 256 MB to the Redis server. Since the plugin compresses the cache using gzip to lower memory usage, it should be more than enough to store all the page caches.

Next, add the following memory policy to ensure that Redis evicts older caches to make room for fresh ones.

maxmemory-policy allkeys-lru

Restart the Redis server after saving your changes in the configuration file. Here’s the command to restart Redis:

sudo systemctl restart redis.service

4. Now you need to install and activate the Redis Page Cache plugin. You can either install it manually from its open source GitHub repository or directly via WordPress.org.

Note: If you install the plugin directly via WordPress.org, the plugin’s slug (or its directory name) is pj-page-cache-red. But if you download it directly through its GitHub repo, the slug is redis-page-cache. Remember where you’ve installed from as you need to use the correct slug in the next step. 

5. Next, you need to create

cd /var/www/your-domain.com/wp-content

You can now create a symlink inside the wp-content directory by using the ln -s command.

sudo ln -s plugins/pj-page-cache-red/advanced-cache.php advanced-cache.php

6. Finally, you need to enable page caching in your WordPress site by editing its wp-config.php file.
Add the following code snippet above the line that says /* That’s all, stop editing! Happy blogging. */

define( 'WP_CACHE', true );

Note: The location where you add the above code snippet is very important.

You’ve finished setting up Redis Page Cache for your WordPress site. 

Before load testing the website, let’s check whether the page cache works as intended. You can test this by visiting the site in incognito mode, or by using the cURL command:

curl -v https://example.com -o /dev/null

If the page cache is working as intended, then you should see an X-Pj-Cache-Status response header with the hit value.

< X-Pj-Cache-Status: hit

If the value shown is “miss” the first time around, try running the command again or refreshing the page. You need to do this as the cache gets saved only after the page has been loaded at least once.

Congrats, you’ve now verified that Redis Page Cache is working on your website. 

You can also configure the Redis Page Cache plugin to define how it should work. For this example, I’ll stick to the default settings.

Stress Test with Redis Page Cache Enabled

Let’s stress test the dummy site to see how it holds up with Redis Page Cache enabled. I’ll fire up loader.io and perform the load test with the maximum number of concurrent clients set to 100.

I repeated the test five times to ensure that the results are consistent. With an average response time of 478 ms and no errors, we can conclude that the site works splendidly with the page cache enabled. 

As the number of concurrent clients increases (the green line), the response time stays relatively constant (the blue line). That’s one of the best indicators that a server can handle many active users without affecting page load speed.

Let’s perform the test again, but this time with a maximum of 200 concurrent clients.

The site still performs well with no errors and an average response time of 757 ms.

In the graph above, you’ll notice a spike in response time at the 22-second mark. After this point, the server response time climb upwards as the number of active clients increases. According to a study by rackAID, you need to keep your server response time less than 500 ms to maintain a good user experience. 

At the end of the test with 200 active users, the server response time climbed to over 1200 ms. That’s far from ideal. 

Note: Caching is just one of the many ways to reduce server response time. For more information on this topic, refer to WP Rocket’s article on reducing TTFB.

Serving 78 concurrent clients with no performance loss is excellent. Assuming that every user spends an average of 2 minutes on any page, it translates to serving over 1.5 million page requests every month facing no server hiccups.

Let’s push the server’s limits more. I’ll stress test it again with the maximum number of active clients set to 250.

The results look consistent with the previous test, but this time 5.1% of the server’s responses were HTTP 400/500 errors. Looking at the Details tab will give us more information about when the error responses first occurred.

The HTTP 500x errors first occurred at the 51 second mark. The total number of active clients was 218 in the test.

The data points above will give you a fair idea of how many active clients the site can handle without errors. 

From the above tests we can conclude that Redis Page Cache improves the performance of the site considerably. Now let’s move on to testing the site with NGINX FastCGI Cache enabled.

What is NGINX FastCGI Cache?

NGINX is a popular, high-performance web server that can host WordPress sites. Apart from being a web server, it’s also used as a reverse proxy, mail proxy, load balancer, and HTTP cache.

As per W3Techs, 32.1% of websites are installed on an NGINX web server (May 25, 2020). Most performance-focused WordPress hosts use NGINX to power their websites today.

Caching on NGINX is mainly powered by its FastCGI Cache module. According to a benchmarking test done by SpinupWP, NGINX FastCGI Cache was the fastest and the most efficient caching solution of the lot.

How to Enable NGINX FastCGI Cache

You can only enable NGINX FastCGI Cache on a web server that has NGINX installed. Since I’ve already installed NGINX as my webserver, I’ll just reset it to its base configuration to remove any traces of Redis.  

You can learn how to use NGINX FastCGI Cache on your WordPress site by visiting WP Rocket’s article on NGINX caching. You can also check out our Caching Dynamic Content in WordPress article for an in-depth tutorial on how to enable NGINX FastCGI Cache.

Before stress testing the site, let’s verify that FastCGI Cache works on the site by checking its response headers.

Now let’s move ahead with the stress test on loader.io.

Stress Test with NGINX FastCGI Cache Enabled

First, I’ll test the site by setting the maximum number of active clients to 100.

As expected, the site performs exceptionally well after enabling page cache. The average server response time stays below 400 ms even as the number of active clients reaches 100 (the maximum number set by me).

Now let’s increase the maximum number of active clients to 200 and repeat the stress test.

Even after increasing the max number of active clients, the average server response time still stays below 400 ms. We already have a clear winner. 

But how far can we push the server? Loader.io allows you to set the maximum number of active clients to a whopping 10000. So, I tested with this max setting to see whether the server will keep up.

Surprisingly, the server kept up. However, the test results showed a 19.7% error rate (timeouts in this case) and an average server response time of 4464 ms.

I kept reducing the max number of clients by half to find out the site’s stress limit with NGINX FastCGI Cache enabled. Finally, I arrived at two numbers. 

With the max number of active clients set to 800, the average server response time is 596 ms. However, the server timeouts start towards the end of the test after reaching 760 active clients. The stress limit for NGINX FastCGI Cache is 3.5x times that of what we observed with Redis Page Cache.

I’ll perform another stress test to find the number of active clients the server can handle without compromising on average response time (<500 ms). For this test, I’m setting the max number of concurrent clients to 500.

The server’s response time reaches over 500 ms at the 44 second mark and keeps moving upwards. The number of active clients at this point is 375. Hence, we can deduce that the server can handle 375 concurrent clients without affecting the response time. That’s 4.8x times the number of active clients supported by Redis Page Cache.  

Assuming that every user spends an average of 2 minutes on any page, it translates to serving 8.1 million page requests every month facing no server hiccups. Not bad for a site hosted on a $10/month server.

Summing Up The Stress Tests

Redis Page Cache is a smart implementation of full-page caching for WordPress sites. Compared to having no page caching enabled, it helps improve the site performance considerably. 

However, NGINX FastCGI Cache beat Redis Page Cache in all the stress tests performed. Below is a comparison chart of both their stress tests. The results are conclusive and speak for themselves.

Wrapping Up

You don’t need expensive hosting to optimize your site’s performance if you know how to enable page caching. Almost all managed WordPress hosts do exactly this to speed up WordPress sites.

If you’d like to dive deeper, you can club NGINX FastCGI Cache with Redis object caching to optimize the site’s performance even further. There’s also a custom NGINX configuration for WP Rocket called Rocket-Nginx. It enables NGINX and WP Rocket to serve cached files directly without calling WordPress or running PHP. 

Page caching is an excellent choice to speed up your website. Choosing the right page caching solution for your WordPress site can be highly confusing. I hope this article answered some of your doubts. 

If you’re still not sure about WordPress page caching or are stuck somewhere, don’t hesitate to leave a comment below!

If you want to speed up your WordPress site, you’ve almost certainly come across the concept of caching.

Nginx caching offers a different approach to caching than the WordPress caching plugins you might be familiar with, though.

In this post, we’ll dig into the topic of Nginx caching for WordPress, starting with an introduction to Nginx and the Nginx FastCGI cache module and finishing with a look at how to use Nginx caching with WordPress.

What is Nginx?

Before we can talk about Nginx caching for WordPress, it’s important to discuss what Nginx actually is.

Nginx is a popular web server, which is the underlying software that powers your WordPress site’s server.

Most cheap shared WordPress hosts use a different web server called Apache, but Nginx is popular with performance-focused managed WordPress hosts and is used by a majority of the world’s high-traffic websites.

According to W3Techs, Apache leads the overall web server market with 44% market share, while Nginx sits in second place at 30.7%. Nginx is a younger technology though and is rapidly expanding its market share.

Nginx offers a different asynchronous approach from Apache, where requests are handled in a single thread and one master process can control multiple worker processes. Unlike Apache, Nginx can handle thousands of HTTP connections at the same time, which can make Nginx a superior option for high-traffic/high-concurrency sites.

You don’t necessarily need to choose between Apache and Nginx, though. Some hosting stacks use Apache as the web server with Nginx in front acting as a reverse proxy.

How Does Nginx Caching for WordPress Work?

At a high-level, Nginx caching does something similar to caching plugins like WP Rocket.

When someone visits your WordPress site, your server needs to execute PHP and query your database to deliver the final HTML product to your visitors’ browsers. Caching works by storing that final HTML product and automatically delivering it to visitors, instead of dynamically rendering your content for each visit.

By eliminating that backend processing, caching can speed up your site and lessen the load on your server.

Nginx lets you do something similar via its fastcgi_cache module but at a server level. That is, Nginx is able to directly serve up your cached content without needing to involve PHP or WordPress.

In contrast, with a caching plugin, each request still needs to be handled by PHP at the application level. A caching plugin still eliminates much of the work and is definitely a positive for your site, but it also requires more CPU cycles than using Nginx to handle the request at a server level.

For example, Delicious Brains benchmarked Nginx FastCGI cache vs Varnish (another caching mechanism) vs the Simple Cache plugin at WordPress.org vs vanilla WordPress and found that Nginx FastCGI cache…

• Processed the most requests per second
• Had the lowest response time

Here are their results for the average response time (lower is better):

How to Use Nginx FastCGI Caching for WordPress

There are a few different ways that you can start using Nginx FastCGI caching with WordPress…

The Simplest Option

If you’re not a technical user, or just don’t want to deal with setting everything up, the simplest solution is to choose a WordPress host that supports Nginx caching out-of-the-box.

Many performance-focused WordPress hosts use the Nginx web server and/or use Nginx FastCGI cache. For example, both Kinsta and Flywheel use Nginx and its FastCGI cache module.

This gives you all the benefits of the Nginx FastCGI cache without requiring any technical knowledge.

The Middle Option

If you prefer something a little bit more flexible but don’t want to go all the way to setting up your own Nginx hosting stack, you can also use a tool like SpinupWP from Delicious Brains.

SpinupWP makes it really easy to host WordPress sites on your own DigitalOcean droplet and lets you enable Nginx FastCGI caching with the check of a box. From the SpinupWP dashboard, you can also set a custom cache duration and enter cache exclusion rules:

You’ll also be able to purge the Nginx FastCGI cache right from your WordPress dashboard.

The Advanced Option

If you’re more advanced, you can also set up your own server using Nginx and the Nginx FastCGI cache module. If you need help activating Nginx’s FastCGI cache module, you can follow this guide from DigitalOcean.

Then, to integrate Nginx FastCGI cache into WordPress, you can use the free Nginx Helper plugin at WordPress.org.

Nginx Helper has a few features to help your WordPress site work with Nginx, but the most relevant one here is the ability to purge the Nginx cache.

First, it adds a new Purge Entire Cache button that lets you manually purge the Nginx FastCGI cache as needed from your WordPress dashboard.

Second, it also lets you set up automatic purge rules. For example, you can automatically purge some or all of your content when you add, modify, or delete WordPress content:

In order to properly set up Nginx Helper with the Nginx FastCGI cache module, you’ll also need to make a few changes to your Nginx configuration files, which the plugin’s developer details here.

WP Rocket Works With Nginx and Nginx FastCGI Cache

WP Rocket offers out-of-the-box compatibility with Nginx, so you don’t need to do anything special to use WP Rocket with the Nginx web server.

To replace WP Rocket’s .htaccess rules on NGINX, Maxime at SatelliteWP created a Rocket-Nginx configuration which you can find at GitHub and learn more about in this knowledgebase article.

You can use both Nginx FastCGI cache and WP Rocket’s page caching, though we don’t recommend this approach. However, if you decide to use them together and the Nginx FastCGI cache misses, WP Rocket can still serve up cached content at the application level.

If you use the Nginx Helper plugin mentioned above, you’ll be able to purge both the Nginx cache and the WP Rocket cache when you clear your cache.

Conclusion

By the numbers, Nginx is the second-most popular web server after Apache and is rapidly growing in popularity, especially with high-traffic sites.

Nginx excels in high-traffic situations and when serving static content. And you can either use only Nginx, or also put Nginx in front of Apache as a reverse proxy.

With the Nginx FastCGI cache module, you can serve static files directly from your server without needing to use PHP or hit your WordPress application, which is different than how most WordPress caching plugins function.

To use Nginx caching on WordPress, the simplest option is to choose a host that’s already configured everything for you. For example, Kinsta and Flywheel automatically use the Nginx FastCGI module for caching.

A good middle-ground is to use something like SpinupWP. SpinupWP lets you use your own DigitalOcean droplet, but gives you a convenient dashboard that lets you enable Nginx caching by checking a box.

Or, the most advanced option is to set up your own Nginx hosting stack. You can then use the free Nginx Helper WordPress plugin to automatically purge the cache according to rules that you choose.
Finally, WP Rocket offers out-of-the-box compatibility with Nginx servers, and you can also use the Rocket-Nginx configuration from Maxime to let Nginx serve previously-cached files without calling WordPress or PHP.

How many types of caching do you know and use on your WordPress site?

If you’re using a WordPress cache plugin like WP Rocket, there’s no doubt you’re already profiting from its browser and page caching features. And if you’re also using its advanced caching options, then your site is enjoying mobile and user caching too.

Then there’s server-side caching (like Varnish or NGINX), and CDN caching: the first depends on the hosting you’re using, while the second on the CDN service you chose.

The last type of caching you’ll want to add to the group is object caching: this is important to make your database queries run faster and finally improve your website speed.

In this post, we’re going to explore the secrets of object caching and dive into one of the most popular object caching systems: Memcached.

Memcached shouldn’t be confused with memcache, which is a PHP extension created for Memcached caching service, and it’s out of the scope of this post.

Memcached And Object Caching Explained In Plain English

Before getting into the details of Memcached, let’s explain what object caching does precisely.

If page caching takes care of caching static resources (images, HTML, CSS and JS files) and browser caching manages the same resources within the browser, object caching is devoted to your database.

The aim of object caching is to cache query results from your database. You can find a detailed explanation of what object caching is on our blog.

An efficient database is one of the crucial factors for a fast website: WordPress is a content management system which is naturally dependent on its MySQL database.

Every time users (or crawlers) make a request on your website, they generate database queries. If your site experiences a large number of requests to the database, queries can quickly pile up, overwhelming your server and slowing down your website.

The good news is the WordPress introduced its object caching class a long time ago: it was 2005 when the class named WP_Object_Cache was implemented into WordPress core.

What Does WordPress Object Caching Do?

WordPress built-in object caching saves a copy of complex queries and stores their results in a database table (i.e., like a HTTPS redirect).

The most frequently used queries running on the pages of your site are stored on the database: this copy of the requests allows to reduce load time and make your website more performant.

Of course, this process is not a prerogative of WordPress sites: the same thing happens on all sites where an object caching system has been implemented.

For example, Drupal, which is another very popular content management system, implements a similar built-in object caching system.

If object caching is working, your server won’t have to regenerate queries’ results every time, but it can use the object caching layer previously created.

To store an object cache, you can use different technologies: among the most popular object caching engines are Memcached, Redis, and APC.

What is Memcached?

Memcached is an open source distributed memory caching system built to ease database load for dynamic web applications like e-commerce stores or websites where login/registration is needed.

Memcached was initially developed by Brad Fitzpatrick in 2003 and is now used by Facebook, Twitter, YouTube, Wikipedia, and other big and small web applications.

Its developers define it as follows:

Memcached is an in-memory key-value store for small arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.

(source)

This system stores key-values data for string and objects, such as:

• API calls
• Page rendering
• Results of database calls

Memcached uses a client-server architecture based on four components:

• A client-server, which retains the list of available Memcached servers
• A client-based hashing algorithm, which picks up a server based on the requested “key.“
• A server software, which stores the combinations of values + key into an internal hash table
• A Least Recently Used (LRU) algorithm, which decides when to use old data or the memory

How Memcached Works

Memcached works like other caching systems, but now the database is at the core of the process.

Let’s see the workflow in five quick steps:

1. The client-server receives a query from a user (i.e., access to a specific URL of a website with an HTTPS redirect);
   
   
2. The client-server checks with the Memcached server if the data needed is already stored in its memory;
   
   
3. If the data exists, Memcached directly returns it to the client server;
   
   
4. If the data isn’t already saved in the cache, Memcached forwards the request to the database;
   
   
5. Requested data is now forwarded to the client-server and, at the same time, the Memcache index is updated with these latest values: the cache is now ready to be used in the future (see step 3).

Typically, Memcached is set up via different Memcached servers and clients, which help to distribute the load of the requests.

The client-server uses the hashing algorithm to decide which Memcached server the request should be forwarded.

It’s important to note that Memcached servers don’t share data: so the database sends data only to one Memcached server at a time.

How To Use Memcached On Your WordPress Site?

The first condition to use Memcached on your WordPress site is that your hosting server has it installed.
The second condition is that your web application can support Memcached.

Since Memcached is solely relying on RAM, it doesn’t require too many CPU resources.

Several web hosting services come with pre-installed Memcached system on their cloud servers: you can find some examples on A2 Hosting, Cloudways or Siteground.

If your server supports Memcached, it’s very likely that you can use it through the pre-built Memcached PHP extension.

What Are The Benefits Of Using Memcached On Your WordPress site?

The main advantage of Memcached is that all information is stored in RAM: this means it doesn’t need to be loaded from the disk each time.

Another advantage is that there are no data restrictions: you can use Memcached to cache a number of different data, such as documents, images but, above all, much more complex structures.

Furthermore, depending on the usage environment you set up, the failure of one of the Memcached servers isn’t usually critical. Most of the time, in fact, Memcached is used as a read-only cache or to hold temporary information. If you use it for persistent data, you can recede to an alternative lookup method which reloads the data into RAM of a different server.

Is WP Rocket Compatible With Memcached?

Being a plugin focused on page caching, WP Rocket doesn’t take care of object caching. So you won’t find any specific Memcached option.

This doesn’t mean you can’t use Memcached with WP Rocket!
To use WP Rocket and Memcached together, you’ll need to install an additional plugin.