Does the world need one more post about a comparison between WordPress caching plugins? I don’t know. However, I do tend to get obsessed with certain tasks and here I am, installing test WordPress instances and adding caching plugins.
It is fun, too.
- The choice of caching plugins
- The configuration of the caching plugins
- WordPress caching plugins test results
- GTmetrix (WooCommerce Not Filtered)
- Pingdom (WooCommerce Not Filtered)
- GTmetrix (WooCommerce Filtered)
- Pingdom (WooCommerce Filtered)
- Impact of the WordPress caching plugins on the CPU usage
- Yasakani Cache
- WP Super Cache
- Swift Performance Lite
- Conclusion
Most of the reviews I’ve read concentrate on the access speed improvements that can be achieved by this or that plugin. However, since I work for a web hosting company, the matter has an extra dimension for me and my colleagues. Our company (ICDSoft) provides a shared hosting service and we usually recommend the use of caching plugins to users who are already pushing the limits of their shared hosting accounts. The WordPress caching plugins do provide an option to squeeze more performance within the same limits. They also save our clients money by delaying the moment when they will have to upgrade to a plan that provides more resources as the popularity of their sites grows.
In this article, I’ll try to explore the improvement of the access speed from one side, and the reduction of CPU usage from another.
The choice of caching plugins
I guess, the choice of plugins for this test may seem odd.
I’ve always contemplated the idea of a WordPress blog that uses an SQLite database instead of MySQL. There is even a plugin that does that. However, it is quite cumbersome. You can’t switch an existing WordPress installation from MySQL to SQLite. The blog has to be installed with this option from scratch. I’ve tested it, though, and the blog was blazing fast. Unfortunately, the last update of the plugin was made 4 years ago and it is basically unsupported. Using such plugins is risky, to say the least. So, what is the next best thing? Well, a caching plugin that stores the cached data in an SQLite database. Here comes the relatively unknown Yasakani Cache plugin which does exactly that.
Swift Performance Lite is the free version of the paid Swift Performance plugin. However, even the free option is getting rave reviews by the users. That naturally sparked my interest and I decided to test what the price of these access speed gains is.
WP Super Cache is an established tool, developed by the same company that maintains WordPress itself - Automattic. It is the default plugin that we recommend to our users. This makes it a natural base for comparison.
So, we have The Underdog (Yasakani), the New Kid On The Block (Swift Performance Lite), and The Veteran (WP Super Cache).
I opened four shared hosting accounts on our Business hosting plan (100 GB of disk space and 1000 GB of traffic per month) - one for each plugin and a control account to run a WordPress installation without any caching.
One and the same free theme was installed for all WordPress instances. The particular theme was chosen because it offers a plugin for sample content import, which builds one of those eye candy, feature-rich front pages. And all this with a just a few clicks.
Actually, the WordPress script was installed just once. Then I cloned it to the rest of the accounts and just added the caching plugins. Our Control Panel allows creating manual backups of the user files and databases. These backups can be easily imported to other accounts on our side. This makes the above cloning rather easy and straightforward.
WP-CLI and SSH access are available for free to all hosting accounts that are provided by ICDSoft and this allows for an easy update of the WordPress URLs when one blog is moved from one location to another and the address gets changed.
In order to make the testing of the CPU usage as clean as possible, the following configuration steps were taken:
- The automatic WordPress core update and cron job were disabled with the following lines in the wp-config.php file:
define( 'WP_AUTO_UPDATE_CORE', false ); define('DISABLE_WP_CRON', 'true'); - The WordPress cron job was scheduled to run once every hour.
- During the testing period, I stayed away from the WordPress Dashboard and made sure that there are no browser windows with the Dashboard opened in order to keep admin-ajax.php at bay.
I expected the test process to go in two stages, but it actually went in three:
Stage I: I used the default account to test the access speed for each plugin with two external tools - GTmetrix and Pingdom. Currently, our servers support PHP 5.6, PHP 7.1, and PHP 7.2. For each plugin I made three runs with each PHP interpreter:
GTmetrix x (non-cached + three caching plugins) x (three PHP versions) Pingdom x (non-cached + three caching plugins) x (three PHP versions)
After the round of tests for the particular plugin, I restored the WordPress instance from backup to its default state before installing and testing the next plugin.
Stage II: The second stage was dedicated to testing the impact on the CPU usage of each caching plugin. The impact of the different PHP interpreters was tested, too.
Three of the opened hosting accounts were configured with one of the tested plugins. One of the accounts was not using a caching plugin. The accounts were running with the particular PHP interpreter for 24 hours (PHP 5.6, then PHP 7.1, then PHP 7.2).
During this period, a browser was configured to access each of the sites twice every minute.
At this stage, I noticed a strange anomaly. The daily CPU usage for each account was abnormally high, despite the use of caching plugins. Then I noticed a strange request to:
wc-ajax=get_refreshed_fragments
It was slow and on top of that, it was not cached.
The demo content installer of the theme was also adding the WooCommerce shopping cart. The above request belongs to this plugin.
The purpose of the request is to gather information about the current items in the shopping cart so that they can be referenced on the other pages. However, very often the WordPress themes do not require such a reference at all, and this ajax call turns into a pure waste of resources.
The following tutorial provides directions on how to exclude some pages and posts from making such a request.
It even gives directions how to limit it only to the WooCommerce-related pages. We did exactly that and started the CPU test over.
Stage III: I repeated GTmetrix and Pingdom tests from Stage I with the optimized WordPress installations.
The configuration of the caching plugins
Quite intentionally, I did not spend a lot of time configuring the caching plugins. Some tweaks were required, though. The life of the cache was set to be one hour for each of the plugins.
Yasakani Cache - the interface of this plugin states that it works faster if you prepend automatically a script to all the WordPress .php files. The suggested approach to carry out this task on our side is to create a file named .user.ini in the WordPress root folder and enter the content that is suggested by the plugin to this file. The code that was suggested in our case was:
auto_prepend_file = "/home/yasakani/www/www/wp-content/yasakani-cache-exload.php"
The script also includes the option to minify the code of the WordPress pages.
WP Super Cache - according to our tests in the past, the script runs most efficiently if the so-called Expert mode is enabled. Normally, it adds certain mod_rewrite directives to the .htaccess file in the root folder of the WordPress installation. So, we enabled this mode and made sure that the directives were added to the .htaccess file.
Swift Performance Lite - when activated, the plugin guides the user through a short configuration wizard. We also disabled the gzip compression, which was enabled by default. This additional step was taken in order to unify the configuration with the other plugins, which were not using gzip compression of the output.
WordPress caching plugins test results
Let me start with the results from the two sets of tests with GTmetrix and Pingdom. The tables below list the access speed in seconds, measured by the two services:
GTmetrix (WooCommerce Not Filtered)
| No Caching | Yasakani | WP Super Cache | SP Lite | ||
| PHP 5.6 | Test 1 |
2.300 |
2.500 |
1.700 |
2.800 |
| Test 2 |
2.400 |
1.800 |
1.700 |
2.500 | |
| Test 3 |
2.400 |
1.800 |
2.600 |
1.700 | |
| Average for PHP 5.6 |
2.367 |
2.033 |
2.000 |
2.333 | |
| PHP 7.1 | Test 1 |
2.500 |
1.700 |
1.700 |
2.200 |
| Test 2 |
2.200 |
1.700 |
2.200 |
1.900 | |
| Test 3 |
2.200 |
2.400 |
2.200 |
1.700 | |
| Average for PHP 7.1 |
2.300 |
1.933 |
2.033 |
1.933 | |
| PHP 7.2 | Test 1 |
2.300 |
2.800 |
1.600 |
1.700 |
| Test 2 |
2.100 |
1.800 |
1.500 |
2.500 | |
| Test 3 |
2.200 |
1.700 |
2.700 |
1.700 | |
| Average for PHP 7.2 |
2.200 |
2.100 |
1.933 |
1.967 | |
| Average for all: |
2.289 |
2.022 |
1.989 |
2.078 |
I don’t know why, but the results from GTmetrix seemed to be quite erratic. The differences between two reloads for one and the same plugin, and with the same version of PHP, could reach 900 ms. This was strange.
As expected, the results without a caching plugin were slower, but not that much. The winner here was WP Super Cache. However, the differences in the average results between the plugins were within 100 ms.
One thing became instantly obvious, though. When the Swift Performance Lite plugin was active, the cached pages were heavily pre-processed.
While the size and the number of requests for the other options were relatively stable, the page that was served by the SP Lite plugin was noticeably smaller and the reduction of the requests that were made by the page was drastic: from 46(48) to 14!
Next is the table with results from Pingdom.
Pingdom (WooCommerce Not Filtered)
| No Caching | Yasakani | WP Super Cache | SP Lite | ||
| PHP 5.6 | Test 1 |
2.800 |
1.660 |
1.440 |
1.310 |
| Test 2 |
2.750 |
1.640 |
1.250 |
1.260 | |
| Test 3 |
2.940 |
2.050 |
1.410 |
1.060 | |
| Average for PHP 5.6 |
2.830 |
1.783 |
1.367 |
1.210 | |
| PHP 7.1 | Test 1 |
2.690 |
1.540 |
1.530 |
1.170 |
| Test 2 |
1.950 |
1.420 |
1.430 |
1.160 | |
| Test 3 |
2.150 |
1.890 |
1.480 |
1.160 | |
| Average for PHP 7.1 |
2.263 |
1.617 |
1.480 |
1.163 | |
| PHP 7.2 | Test 1 |
2.570 |
1.810 |
1.320 |
1.200 |
| Test 2 |
2.760 |
1.790 |
1.220 |
1.280 | |
| Test 3 |
2.480 |
1.760 |
1.490 |
1.600 | |
| Average for PHP 7.2 |
2.603 |
1.787 |
1.343 |
1.360 | |
| Average for all: |
2.566 |
1.729 |
1.397 |
1.244 |
The results from Pingdom seemed to be much more straightforward and the benefits of using caching plugins became more obvious.
While almost all results for non-cached pages were above 2 seconds, all but one cached attempt were loaded for less than two seconds. The heavy optimization, applied by Swift Performance Lite, seemed to pay off and the page seemed to load for half the time of the non-cached results. WP Super Cache was a close second. Yasakani was third with quite a respective result, though.
The number of tests per PHP interpreter seemed to be small to draw a statistically valid conclusion. However, both sets of tests (GTmetrix and Pingdom) suggest that the site benefited from the switch from PHP 5.6 to PHP 7.1.
As I mentioned above, the page seemed sluggish and even the cached pages appeared to load slow. After the rogue WooCommerce request was identified and removed, the loading speed improved significantly.
The new round of the same tests is available below:
GTmetrix (WooCommerce Filtered)
| No Caching | Yasakani | WP Super Cache | SP Lite | ||
| PHP 5.6 | Test 1 |
1.900 |
1.300 |
1.200 |
1.200 |
| Test 2 |
2.400 |
1.300 |
1.200 |
1.200 | |
| Test 3 |
2.100 |
1.300 |
1.200 |
1.300 | |
| Average for PHP 5.6 |
2.133 |
1.300 |
1.200 |
1.233 | |
| PHP 7.1 | Test 1 |
1.900 |
1.300 |
1.200 |
1.200 |
| Test 2 |
1.900 |
1.300 |
1.300 |
1.300 | |
| Test 3 |
1.800 |
1.200 |
1.200 |
1.200 | |
| Average for PHP 7.1 |
1.867 |
1.267 |
1.233 |
1.233 | |
| PHP 7.2 | Test 1 |
1.800 |
1.300 |
1.200 |
1.300 |
| Test 2 |
1.800 |
1.300 |
1.200 |
1.500 | |
| Test 3 |
1.800 |
1.300 |
1.400 |
1.300 | |
| Average for PHP 7.2 |
1.800 |
1.300 |
1.267 |
1.367 | |
| Average for all: |
1.933 |
1.289 |
1.233 |
1.278 |
Pingdom (WooCommerce Filtered)
| No Caching | Yasakani | WP Super Cache | SP Lite | ||
| PHP 5.6 | Test 1 |
1.820 |
1.160 |
1.060 |
0.945 |
| Test 2 |
1.830 |
1.160 |
1.250 |
0.887 | |
| Test 3 |
2.540 |
1.260 |
1.170 |
0.979 | |
| Average for PHP 5.6 |
2.063 |
1.193 |
1.160 |
0.937 | |
| PHP 7.1 | Test 1 |
1.660 |
1.390 |
1.150 |
0.908 |
| Test 2 |
2.270 |
1.220 |
1.050 |
1.010 | |
| Test 3 |
2.320 |
1.090 |
0.943 |
1.120 | |
| Average for PHP 7.1 |
2.083 |
1.233 |
1.048 |
1.013 | |
| PHP 7.2 | Test 1 |
1.590 |
1.190 |
1.090 |
1.250 |
| Test 2 |
1.600 |
1.150 |
0.962 |
0.907 | |
| Test 3 |
2.230 |
1.190 |
1.130 |
0.821 | |
| Average for PHP 7.2 |
1.807 |
1.177 |
1.061 |
0.993 | |
| Average for all: |
1.984 |
1.201 |
1.089 |
0.981 |
This time around, even the non-cached pages often loaded for less than two seconds with both services for the particular test site.
Again, the average results from GTmetrix were very close to each other. The winner is WP Super Cache. It offers a 36% reduction of the access time. However, the results of the other two plugins were within a 60 ms range, which makes them basically the same.
The results from Pingdom were quite different and the winner there was more clearly defined. According to this tool, the biggest improvement of the WordPress access speed was achieved with the Swift Performance Lite plugin (50.51% faster). WP Super Cache came second with a 45% access speed improvement, and Yasakani Cache was third with a 39% improvement.
Impact of the WordPress caching plugins on the CPU usage
Speed improvement is always nice. However, with these tests, I also wanted to check what is happening in the background and what is the impact of the usage of caching plugins on the server load, combined with the different versions of PHP that are available on our side. The tests ran over the course of three days. Each PHP version was active for 24 hours:
Dec 19, 2018: PHP 5.6
Dec 20, 2018: PHP 7.1
Dec 21, 2018: PHP 7.2
Our hosting Control Panel has a handy section which lists the summarized statistics about the daily and hourly CPU usage. Screenshots from this section will be used to illustrate the impact on the CPU load.
The control account was not using any caching. So, basically, it will display the effect of just switching the PHP interpreter. The first screenshot was taken after two and a half days. It concentrates on the hourly usage:
The bars from the daily chart that are relevant to our test are the last two. The previous days exhibit a significantly higher daily CPU usage. Those were before the WooCommerce ajax request was filtered.
The switch from PHP 5.6 to 7.1 is clearly visible in the hourly chart. It immediately leads to a 25% drop of the hourly CPU usage. This usage remained the same when the account was switched to PHP 7.2.
Below you can see the daily chart after the test was concluded:
The starting date is highlighted and the daily usage there was 41 CPU minutes, which dropped to 32 minutes after PHP 7.1 was activated. The usage remained the same after the switch to PHP 7.2. In other words, there is really no point staying on PHP 5.6, unless you have a specific reason, such as incompatible third-party plugins and themes. Even then, it is worth exploring the option to make them compatible with the newer versions of PHP. Furthermore, the recommended version of PHP by WordPress.ORG is PHP 7.2.
Yasakani Cache
The same test of the Yasakani Cache plugin revealed that even the usage of such a modest plugin can lead to a huge improvement of the CPU usage. It shows a stable hourly usage that does not seem to be affected by the switch to the different versions of PHP:
The daily usage is 7 CPU minutes for all days of the tests. Compare this to the 41/32 minutes without a caching plugin and the benefit is immediately obvious.
WP Super Cache
The WP Super Cache plugin shows similar behavior with an even bigger reduction of the CPU usage. The daily usage goes down to 5 minutes for PHP 5.6 and to 4 CPU minutes for PHP 7.1 and 7.2.
Swift Performance Lite
The SP Lite plugin generated the most interesting CPU-related statistics. Although the pages that are served when this plugin is active are blazingly fast, there is almost no reduction of the CPU usage when PHP 5.6 is active. I believe that this is somehow related to the active approach of this plugin towards the cached pages. As I mentioned earlier, these pages are heavily modified and optimized. Looking at the source, it seems that certain images and font data get integrated directly into the cached pages. This reduces the number of requests that are made by the pages. However, the optimization process inevitably takes additional resources and raises the CPU usage.
Strangely, the issue applies only to PHP 5.6. The CPU usage settled down immediately after the switch to PHP 7.1, which suggests that something else about this plugin may not be optimized for PHP 5.6. The screenshot of the hourly usage is available below and the huge drop is clearly visible at 00:00 on Dec 20, 2018:
Actually, the CPU usage of WordPress with the Swift Performance Lite plugin seems to correlate directly with the version of PHP that is applied. The CPU usage was further reduced when the account was switched to PHP 7.2. The daily usage was as follows:
PHP 5.6: 46 minutes
PHP 7.1: 7 minutes
PHP 7.2: 5 minutes
I was quite surprised by these results. The PHP 5.6 result seemed like an anomaly and I got curious if I’m not missing something. That’s why, I switched the site back to PHP 5.6 on Dec 23, and the CPU usage immediately went up. This made me confident that this is the standard behavior of the plugin.
Conclusion
There is no doubt that caching plugins like the ones that were tested here do bring a significant benefit to the sites that are using them. Of course, there may be cases when the use of such plugins is not advisable. For example, if the main purpose of your WordPress-based site is to be a shop, showing your products on your front page, then most likely, it is better to keep the site fully dynamic. However, if you have a content-based site with posts and pages that show static content, then there is no reason to pull this content from the MySQL database each time the pages are loaded.
The users will also have to decide what is their main goal: speed optimization, optimization of the usage of resources, or both.
The Swift Performance Lite does offer the best speed optimization from the tested three plugins. It produces cached pages that load much faster than the ones that are generated by the other plugins. However, this does come at a certain cost. The tested site had a small number of pages and we loaded just the front page during the test. However, if you have a large site with hundreds or thousands of pages, then this active approach towards the generation of the cached versions may lead to a considerable usage of server resources. If you are using a shared hosting account, you can afford to risk with this plugin if you have a site that is not that big and busy, and your account is not close to the limits of your service. The plugin has many configuration options and you may be able to find a combination that keeps things in a healthy balance, though.
WP Super Cache and Yasakani Cache improve both the access speed and the CPU usage in a very straightforward way, without potential surprises.
They offer similar performance, but WP Super Cache is both faster and more efficient than Yasakani. Most likely, this is related to the chosen Expert mode, which relies heavily on mod_rewrite. The delivery method of Yasakani relies on PHP and SQLite, which is inevitably slower than the mod_rewrite approach.
As a strong point for Yasakani, I can mention that it minifies the code of the cached pages and reorganizes the loaded JavaScript files a bit. This leads to a minimal reduction of the page size, but this plugin is still the slowest of all.
So, if you would like to be on the safe side and reduce the server load while speeding your site up, you can choose between these two plugins. The logical choice would be WP Super Cache. Yasakani Cache also offers respectable performance, but I can’t think of a particular reason to choose it over WP Super Cache. Of course, if you would like to support the developers, you can use it too. It will definitely benefit your site.
Of course, this test does not pretend to be an extensive review of all the available caching plugins for WordPress. There are many other solutions that you can choose from, both paid and free. Other popular plugins are W3 Total Cache, WP Rocket, Comet Cache, etc. We can't cover them all, but you are free to test them, evaluate their performance, and find the one that works best for your site.
By Support 58
