Select Page

What Is The Best WordPress Caching Plugin?

by | Nov 30, 2020 | WordPress, Review

This post may contain affiliate links, which means we may earn a commission if you use one of our links. Learn more.

One of the easiest ways to give your WordPress website a performance boost is by utilizing a WordPress caching plugin. However, out of all the choices available, which one is the best? Well, in this post, that’s what we’re going to find out through a series of tests.

Testing Methodology

In order to test which WordPress caching plugin is the best, we’ll be running two types of tests for each one. The first test will be an optimization and load time test using GTmetrix. We will run three tests for each plugin, and calculate the average. The second test will be a load test and see how much concurrent traffic the server can handle with each plugin. We will be focusing only on page caching and minificiation if applicable.

The load tests will be done using the apache bench tool with the following commands until we start seeing errors:

ab -n 100 -c 10 https://example.com/
ab -n 100 -c 25 https://example.com/
ab -n 1000 -c 100 https://example.com/

All tests will be made on the same WordPress installation. The installation will be hosted on a $5 DigitalOcean VPS, which has 1 vCPU and 1 GB of RAM along with 25 GB SSD storage. 1 GB of RAM is pretty common in shared hosting plans, so the results should translate to shared hosting as well. In order to not benchmark an empty website, we will use the FakerPress plugin to generate 100 fake posts. The default WordPress theme will be used, with no other plugins.

Additionally, the apache bench tests will be run a server in the same data center to make sure we’re testing the server’s capacity and not the internet bandwidth (for those of you wondering, the latency was less than 1ms between the two servers). The server will be running Ubuntu Server 20.04, and running Apache with PHP 7.4 with OPcache enabled along with MySQL 8.0.22

How Do WordPress Caching Plugins Work?

One of the most appealing aspects of WordPress are its feature set and flexibility. One of the defining features of WordPress is that it’s a dynamic website instead of a static one. What this means from a performance perspective is that instead of simply serving an already written HTML page, WordPress has to run PHP to generate the page. And in that PHP, there are a lot of database calls, which also slow things down.

This design is what makes WordPress so flexible, but it does come at the cost of performance. Additionally, WordPress can be expanded upon and modified with the use of tens of thousands of free themes and plugins, and many premium ones as well, which add even more code that needs to be run.

WordPress caching plugins fix this issue by combining the power of WordPress with the performance of a static website. With a caching plugin enabled, when a visitor visits your website, one of two things will happen. If a cached version of the requested page is available, and the user is not logged in, then the already generated HTML page is served instead of generating it again. If the requested page is not available in the cache, then the page is generated as normal, but the output is saved to a file. All subsequent requests can then be served that cached version.

This significantly reduces both the stress on the server and load times. Reduced load times mean a better experience for visitors, and possibly even an SEO boost. Less stress on the server means that your server will be able to handle more connections at once, which you’ll need as your website continues to grow. So, if your website is running slow, it’s worth trying out a WordPress caching plugin before deciding its time to upgrade your hosting plan.

With that out of the way, let the benchmarking of the WordPress caching plugins begin!

Note: The caching plugins aren’t really listed in any specific order.

No Plugin

There’s not much to say here. This is just to get a baseline so we have something to compare to. Here are the GTmetrix results:

The results without a caching plugin are pretty good, with an average fully loaded time of roughly 1.2 seconds. I also find it interesting that the performance grade changed for each test, but that doesn’t really have anything to do with the rest of the tests. Where I think the server will struggle without a caching plugin is in the load tests.

And for the load tests:

10 concurrent connections:

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        102188 bytes

Concurrency Level:      10
Time taken for tests:   5.658 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      10243500 bytes
HTML transferred:       10218800 bytes
Requests per second:    17.67 [#/sec] (mean)
Time per request:       565.836 [ms] (mean)
Time per request:       56.584 [ms] (mean, across all concurrent requests)
Transfer rate:          1767.90 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:   340  558  68.8    542     786
Waiting:       33  167  51.8    154     322
Total:        341  559  68.8    542     786

Percentage of the requests served within a certain time (ms)
  50%    542
  66%    558
  75%    568
  80%    577
  90%    675
  95%    710
  98%    734
  99%    786
 100%    786 (longest request)

So far, we haven’t encountered any server errors which is good. All of the requests were able to be served in less than 800 ms, and the server was able to serve 18 requests per second. While that’s not bad, I think we can do a lot better.

25 concurrent connections:

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        102188 bytes

Concurrency Level:      25
Time taken for tests:   6.260 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      10243500 bytes
HTML transferred:       10218800 bytes
Requests per second:    15.97 [#/sec] (mean)
Time per request:       1564.983 [ms] (mean)
Time per request:       62.599 [ms] (mean, across all concurrent requests)
Transfer rate:          1598.01 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.4      0       2
Processing:   650 1484 402.8   1465    2311
Waiting:       37  761 363.5    906    1815
Total:        652 1485 402.7   1466    2313
ERROR: The median and mean for the initial connection time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%   1466
  66%   1548
  75%   1608
  80%   1929
  90%   2097
  95%   2202
  98%   2312
  99%   2313
 100%   2313 (longest request)

The server was also able to handle 25 concurrent requests, but the load time definitely took a hit. Half of the requests took longer than 1.5 seconds, and the longest request took over 2 seconds. The requests per seconds was also roughly the same, at 16. It is worth noting that apache bench only checks how fast the server is able to send the web page over; it doesn’t include the time to fetch other assets (e.g. CSS, JavaScript, images, etc.), but this is just a load test after all.

I honestly didn’t think we’d get this far, but here are the results for 100 concurrent connections:

Server Software:        Apache/2.4.41
Server Hostname:        testing.mintyblogging.com
Server Port:            80

Document Path:          /
Document Length:        102188 bytes

Concurrency Level:      100
Time taken for tests:   49.910 seconds
Complete requests:      1000
Failed requests:        753
   (Connect: 0, Receive: 0, Length: 753, Exceptions: 0)
Non-2xx responses:      753
Total transferred:      27477615 bytes
HTML transferred:       27205013 bytes
Requests per second:    20.04 [#/sec] (mean)
Time per request:       4990.972 [ms] (mean)
Time per request:       49.910 [ms] (mean, across all concurrent requests)
Transfer rate:          537.64 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.8      0       5
Processing:    10 4495 10274.1     82   41599
Waiting:       10 2227 5892.7     80   36884
Total:         10 4496 10274.1     83   41600
WARNING: The median and mean for the initial connection time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%     83
  66%    118
  75%   2036
  80%   6782
  90%  15983
  95%  36657
  98%  38859
  99%  40165
 100%  41600 (longest request)

As you can see, the server really started to struggle. More than 70% of all the requests returned a non-200 response, which I suspect is because the server ran out of RAM. The longest request also jumped up to 42 seconds, with more than 25% of requests taking more than 2 seconds. With the baseline testing complete, let’s see what happens with WP Super Cache.

WP Super Cache

The WP Super Cache dashboard

The first WordPress caching plugin we’ll be trying out is WP Super Cache because it’s easy to configure, and made by Automattic, the company behind WordPress. It has over 2 million active installations, and 4.3 stars with over 1200 reviews at the time of writing. Installation is just like any other plugin, and the first page of settings only has two options: one with caching disabled and one with caching enabled. The “advanced” tab shows more options; the only ones of interest to this test will be the caching mode. In order to get the best performance, we will be using expert mode.

First up, here are the GTmetrix results:

Although the performance grades were similar to without a caching plugin, the fully loaded time was a bit faster with an average of 1.2 seconds (without the rounding, it was about 100ms faster). Additionally, the TTFB (time to first byte) also went down by around 100ms. But, where I think we’ll see the biggest improvement with a WordPress caching plugin is with load tests, so let’s try those again:

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        102332 bytes

Concurrency Level:      10
Time taken for tests:   0.166 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      10271300 bytes
HTML transferred:       10233200 bytes
Requests per second:    603.38 [#/sec] (mean)
Time per request:       16.573 [ms] (mean)
Time per request:       1.657 [ms] (mean, across all concurrent requests)
Transfer rate:          60522.81 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:     4   15   5.5     13      32
Waiting:        2   13   5.4     12      30
Total:          5   15   5.4     14      32

Percentage of the requests served within a certain time (ms)
  50%     14
  66%     16
  75%     18
  80%     20
  90%     24
  95%     27
  98%     32
  99%     32
 100%     32 (longest request)

As expected, the use of a WordPress caching plugin drastically improved the load tests. We were able to get the longest request down to 32 ms, with a whopping 603 requests per seconds. Since WP Super Cache in expert mode completely bypasses PHP, I think we’ll see similar metrics for the next two tests.

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        102332 bytes

Concurrency Level:      25
Time taken for tests:   0.180 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      10271300 bytes
HTML transferred:       10233200 bytes
Requests per second:    555.36 [#/sec] (mean)
Time per request:       45.016 [ms] (mean)
Time per request:       1.801 [ms] (mean, across all concurrent requests)
Transfer rate:          55705.25 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.6      0       3
Processing:     4   40  12.1     41      63
Waiting:        2   36  11.2     38      56
Total:          5   40  11.8     41      64
WARNING: The median and mean for the initial connection time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%     41
  66%     45
  75%     50
  80%     51
  90%     53
  95%     56
  98%     64
  99%     64
 100%     64 (longest request)

Surprisingly, the requests per second went down quite a bit, but we’re not even sending that many requests in total so I don’t expect the number to be that accurate. However, the longest request it exactly twice as long but it’s still under 100 ms, so I’d still consider it a win for the caching plugin. Here are the results for the final benchmark:

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        102332 bytes

Concurrency Level:      100
Time taken for tests:   1.259 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      102713000 bytes
HTML transferred:       102332000 bytes
Requests per second:    794.33 [#/sec] (mean)
Time per request:       125.893 [ms] (mean)
Time per request:       1.259 [ms] (mean, across all concurrent requests)
Transfer rate:          79675.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.4      0      15
Processing:    14  120  29.4    114     241
Waiting:        2  117  29.3    112     232
Total:         17  120  29.8    114     247

Percentage of the requests served within a certain time (ms)
  50%    114
  66%    118
  75%    121
  80%    123
  90%    147
  95%    198
  98%    220
  99%    230
 100%    247 (longest request)

As expected, the metrics are quite similar to the other two. The requests per second actually increased to nearly 800, although the requests did take longer to serve. However, there were no server errors so I’d still call this a win. Now, let’s check out the next caching plugin.

Breeze

The Breeze dashboard

Next up is Breeze, which is less known than the other caching plugins on this list. At the time of writing, it has more than a hundred thousand active installations, with a rating of 4.1 stars with just over 60 reviews. However, don’t let that discourage you from trying it out. Similarly to WP Super Cache, Breeze has a really simple interface to a powerful caching engine. Unlike WP Super Cache, Breeze also support minifying HTML, CSS, and JavaScript which will help to decrease the total page load times. For these tests, I enabled all of the minifcation options. So, let’s see how fast Breeze can make our website:

The first page load was slower than expected, but the cache can’t really do much on the first load. Now that the cache should have been generated, let’s see if the next two loads are any faster.

Although the time to first byte is better than the baseline, the fully loaded time was actually worse with it taking an average of 1.4 seconds. However, since I think Breeze can do a bit better, I disabled the inline minifcation options to see if that may have been causing the slow down. Long story short, I wasn’t able to get Breeze to perform any better. Here is the best result out of the three subsequent tests I ran:

Hopefully Breeze fares better in the load tests.

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        13992 bytes

Concurrency Level:      10
Time taken for tests:   0.589 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1433500 bytes
HTML transferred:       1399200 bytes
Requests per second:    169.64 [#/sec] (mean)
Time per request:       58.949 [ms] (mean)
Time per request:       5.895 [ms] (mean, across all concurrent requests)
Transfer rate:          2374.78 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.3      0       2
Processing:     7   56  21.1     56     178
Waiting:        7   54  21.7     55     178
Total:          7   57  21.1     57     178
ERROR: The median and mean for the initial connection time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%     57
  66%     61
  75%     66
  80%     68
  90%     75
  95%     87
  98%    111
  99%    178
 100%    178 (longest request)

Fortunately, Breeze made a huge improvement over the baseline in the first load test. Instead of the 17 requests per second without a caching plugin, Breeze was able to increase that to 170. Additionally, half the requests loaded in under 60 ms while the longest request was around 180 ms. So far, so good. Let’s see how well that performance scales.

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        13992 bytes

Concurrency Level:      25
Time taken for tests:   0.548 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      1433500 bytes
HTML transferred:       1399200 bytes
Requests per second:    182.43 [#/sec] (mean)
Time per request:       137.038 [ms] (mean)
Time per request:       5.482 [ms] (mean, across all concurrent requests)
Transfer rate:          2553.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.4      0       2
Processing:     8  126  34.2    127     198
Waiting:        7  122  35.0    123     198
Total:         10  126  34.1    127     200
ERROR: The median and mean for the initial connection time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%    127
  66%    139
  75%    146
  80%    148
  90%    175
  95%    185
  98%    198
  99%    200
 100%    200 (longest request)
Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        13992 bytes

Concurrency Level:      100
Time taken for tests:   4.998 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      14335000 bytes
HTML transferred:       13992000 bytes
Requests per second:    200.10 [#/sec] (mean)
Time per request:       499.754 [ms] (mean)
Time per request:       4.998 [ms] (mean, across all concurrent requests)
Transfer rate:          2801.18 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.1      0      12
Processing:    12  469 108.3    463    1003
Waiting:        9  463 105.8    456     960
Total:         14  470 108.0    464    1003

Percentage of the requests served within a certain time (ms)
  50%    464
  66%    494
  75%    516
  80%    537
  90%    587
  95%    634
  98%    703
  99%    862
 100%   1003 (longest request)

Although Breeze didn’t perform as well as WP Super Cache here either, it is still a massive improvement over no caching plugin. There were no server errors, and the server was able to serve around 200 requests per second which is pretty good. Where Breeze struggled the most is with response time, but it was still a huge improvement over the baseline.

So it looks like Breeze didn’t perform as well as WP Super Cache. It is worth noting that unlike the other WordPress caching plugins on this list, Breeze doesn’t use the .htaccess file to serve cached pages. This means that although it still caches pages, the web server still has to run PHP, which makes things a lot slower than just using .htaccess rules. On the bright side, this does mean that Breeze will work on web hosts that don’t support .htaccess files.

W3 Total Cache

W3 Total Cache’s General Settings Page

W3 Total Cache is probably the most configurable WordPress caching plugin on this list. However, that does come at the cost of being quite a bit more complex. That being said, its complexity doesn’t stop it from having over 1 million active installations, and a rating of 4.4 stars with over 4600 reviews.

W3 Total Cache has over a dozen pages of settings you can configure, but for this benchmark the only settings we’ll be changing are to enable minification for HTML, CSS, and JavaScript. It is worth noting that W3 Total Cache also supports additional caching methods, such as object caching and database caching which can help boost performance even in cases where the page cache can’t (e.g. the first time someone visits a page, or on pages that can’t be cached). With that out of the way, here are the GTmetrix results:

W3 Total Cache performed pretty well. It is so far the only WordPress caching plugin that was able to get a 100% performance score, and had an average fully loaded time of just 1.2 seconds. Since W3 Total Cache uses .htaccess rewrite, I expect it to perform pretty well on the load tests.

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        92594 bytes

Concurrency Level:      10
Time taken for tests:   0.200 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      9292900 bytes
HTML transferred:       9259400 bytes
Requests per second:    500.37 [#/sec] (mean)
Time per request:       19.985 [ms] (mean)
Time per request:       1.999 [ms] (mean, across all concurrent requests)
Transfer rate:          45408.86 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:     3   18   8.6     16      51
Waiting:        2   16   7.2     14      37
Total:          4   19   8.5     17      51

Percentage of the requests served within a certain time (ms)
  50%     17
  66%     20
  75%     23
  80%     27
  90%     32
  95%     35
  98%     38
  99%     51
 100%     51 (longest request)

W3 Total Cache seems to be performing well right from the start. With the vast majority of requests being served in under 40 ms and with 500 requests per second, I think it’s safe to say W3 Total Cache will perform well on the other two tests.

Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        92594 bytes

Concurrency Level:      25
Time taken for tests:   0.225 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      9292900 bytes
HTML transferred:       9259400 bytes
Requests per second:    444.63 [#/sec] (mean)
Time per request:       56.226 [ms] (mean)
Time per request:       2.249 [ms] (mean, across all concurrent requests)
Transfer rate:          40350.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       2
Processing:     4   49  15.1     50      77
Waiting:        2   46  14.3     48      75
Total:          6   49  15.0     50      77

Percentage of the requests served within a certain time (ms)
  50%     50
  66%     52
  75%     55
  80%     61
  90%     68
  95%     74
  98%     77
  99%     77
 100%     77 (longest request)
Server Software:        Apache/2.4.41
Server Hostname:        ##########
Server Port:            80

Document Path:          /
Document Length:        92594 bytes

Concurrency Level:      100
Time taken for tests:   1.473 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      92929000 bytes
HTML transferred:       92594000 bytes
Requests per second:    679.03 [#/sec] (mean)
Time per request:       147.269 [ms] (mean)
Time per request:       1.473 [ms] (mean, across all concurrent requests)
Transfer rate:          61622.43 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.1      0      10
Processing:     9  140  24.7    141     226
Waiting:        2  138  25.0    140     215
Total:         12  141  24.7    142     226

Percentage of the requests served within a certain time (ms)
  50%    142
  66%    145
  75%    150
  80%    154
  90%    162
  95%    185
  98%    201
  99%    208
 100%    226 (longest request)

Sure enough, W3 Total Cache performed as expected. It was able to serve 670 requests per second, and the longest request out of all the load tests was 226 ms. There were also zero failed requests, and the HTML transferred was the lowest out of the three WordPress caching plugins tested so far, indicating that W3 Total Cache does a good job at minifying resources.

WP Rocket

WP Rocket’s Settings Page

WP Rocket is the only premium WordPress caching plugin on this list, and for good reason. WP Rocket is sort of a combination between WP Super Cache and W3 Total Cache in terms of its ease of use and feature set. The plugin is super easy to configure, and has the nicest interface of any of the caching plugins on this list. WP Rocket claims to implement more than 80% of best practices when it comes to performance out of the box, and it definitely seems that way.

WP Rocket performed more or less the same as the other WordPress caching plugins on the GTmetrix tests. With an average fully loaded time of exactly 1.2 seconds. Let’s see how well WP Rocket handles the load tests.

Server Software:        Apache/2.4.41
Server Hostname:        testing.mintyblogging.com
Server Port:            80

Document Path:          /
Document Length:        92409 bytes

Concurrency Level:      10
Time taken for tests:   0.199 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      9274000 bytes
HTML transferred:       9240900 bytes
Requests per second:    502.81 [#/sec] (mean)
Time per request:       19.888 [ms] (mean)
Time per request:       1.989 [ms] (mean, across all concurrent requests)
Transfer rate:          45537.99 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       2
Processing:     3   18   9.7     16      47
Waiting:        1   15   8.3     13      39
Total:          3   19   9.7     16      47

Percentage of the requests served within a certain time (ms)
  50%     16
  66%     21
  75%     24
  80%     28
  90%     34
  95%     38
  98%     41
  99%     47
 100%     47 (longest request)
Server Software:        Apache/2.4.41
Server Hostname:        testing.mintyblogging.com
Server Port:            80

Document Path:          /
Document Length:        92409 bytes

Concurrency Level:      25
Time taken for tests:   0.197 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      9274000 bytes
HTML transferred:       9240900 bytes
Requests per second:    507.46 [#/sec] (mean)
Time per request:       49.265 [ms] (mean)
Time per request:       1.971 [ms] (mean, across all concurrent requests)
Transfer rate:          45958.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.4      0       2
Processing:     4   43  13.8     44      76
Waiting:        2   40  12.7     43      66
Total:          5   43  13.6     45      76
ERROR: The median and mean for the initial connection time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%     45
  66%     47
  75%     48
  80%     53
  90%     59
  95%     66
  98%     72
  99%     76
 100%     76 (longest request)
Server Software:        Apache/2.4.41
Server Hostname:        testing.mintyblogging.com
Server Port:            80

Document Path:          /
Document Length:        92409 bytes

Concurrency Level:      100
Time taken for tests:   1.345 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      92740000 bytes
HTML transferred:       92409000 bytes
Requests per second:    743.27 [#/sec] (mean)
Time per request:       134.541 [ms] (mean)
Time per request:       1.345 [ms] (mean, across all concurrent requests)
Transfer rate:          67315.35 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.9      0       4
Processing:    10  128  27.5    127     226
Waiting:        2  126  27.7    126     224
Total:         12  129  27.6    127     231
WARNING: The median and mean for the initial connection time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%    127
  66%    129
  75%    134
  80%    136
  90%    162
  95%    189
  98%    206
  99%    214
 100%    231 (longest request)

WP Rocket performed quite well in the load tests, with the lowest longest request time out of all the WordPress caching plugins tested. It was also able to get around 745 requests per second; although lower than WP Super Cache’s 794 requests per second it is still a close second place. The third highest is W3 Total Cache’s 679 requests per second. The HTML transferred also puts WP Rocket in second place for best minification, just behind W3 Total Cache.

Conclusion

Use a WordPress caching plugin! With just a few minutes of installation and configuration, you can boost your website’s ability to handle traffic as well as reduce the load time for your visitor’s. Although all of the WordPress caching plugins performed more or less the same, if I had to give a ranking, this is what it would be:

  1. WP Rocket
  2. WP Super Cache
  3. W3 Total Cache
  4. Breeze

The first, second, and third WordPress caching plugins are ranked pretty close to each other. WP Rocket got first place because of its easy to use dashboard, fastest longest request time, and second highest requests per second. WP Super Cache is an extremely close second because of it’s simple dashboard, and because it was able to get the most requests per second out of the server. W3 Total Cache is an extremely close third because of its configuration options, and decent performance in load tests.

Although Breeze was still a huge improvement over no caching plugin, its performance was disappointing. However, I wasn’t running the plugin in its ideal configuration, which would be behind a Varnish server. After all, the plugin is made by Cloudways and would probably perform better on their hosting.

Additionally, the GTmetrix tests were done with an unthrottled internet connection. So it is entirely possible that Breeze (or any of the other caching plugins with minification) would have performed better with a slower internet connection when compared to the baseline because there is less data that needs to be transported.

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *

Categories