Which is truly the best cache plugin for WordPress?

Today we’re going to talk about a super interesting and useful topic for those who have a WordPress website: cache plugins. These little gems can make all the difference in your website’s speed and performance. So, without further ado, let’s get started.

Why install a cache plugin in WordPress?

Imagine you have a physical store, and every time a customer comes in, you have to go and get the products from the stockroom. It would be exhausting! The same thing happens with your website: every time a visitor lands, the server has to process the request and load all the data and elements of the page, executing PHP and querying the database, which can be slow.

This is where caching plugins come in. Basically, what they do is save a copy of your page in the server’s memory or disk and deliver that copy when someone requests to view it, without any -or almost no- database queries or PHP involved, which speeds up loading times by a lot. In other words, a cache plugin makes your website fly like a rocket, or at least that’s what they all promise…

The experiment

For this “experiment”, we decided to test all the cache plugins available in the WordPress plugin repository that have more than 3,000 active installations -and are not abandoned- on three different web servers: Apache, NGINX, and OpenLiteSpeed. We also included WP Rocket in the list, even though it’s not in the WordPress plugin repository, as it’s probably the most popular caching plugin. Additionally, we didn’t include any of the following plugins:

Hyper Cache, because it simply doesn’t work; you can install it, but no cache file is created.
Any plugin that needs to connect to an external service to function (10Web Booster, FlyWP Helper, etc.).
Any plugin that requires the website to be hosted on a specific hosting provider (SiteGround Optimizer, etc.) to get the most out of it.

The three environments were tested on the same Hetzner server, one of the cheapest (called CX22), with the following specs:

2 vCPU, 4 GB RAM, Ubuntu 24.04, PHP 8.5

To measure actual performance, we decided to run 20 tests in each environment with each cache plugin. In each test, we opened an Incognito window on Brave and got the TTFB and DOMContentLoaded event from the developer tools. Instead of chasing useless scores in tools like PageSpeed Insights or GTmetrix, we focused on TTFB (Time To First Byte), which shows the time it takes from when a user makes a request until they receive the first byte of the server’s response, and the DOMContentLoaded event, which indicates when the initial HTML document has been fully loaded and parsed by the browser, without waiting for stylesheets, images, or other external resources to fully load. TTFB is the primary metric that improves with a cache plugin because the user no longer has to wait for WordPress to execute the plugin’s PHP code or query the database. Other metrics like LCP and FCP also improve, but this improvement is always a result of the TTFB.

To avoid manually reloading the page and checking the values, the 20 tests were done using an automated script run from the browser console. Once the data was collected, we calculated the median (not the mean, which is affected by significantly smaller or larger results). You can see the script used at the end of the article. The times you’ll see are very similar, so they need to be analyzed and viewed in a relative and appropriate context.

If one plugin has a median latency of 781 ms and another 782 ms, you can’t definitively conclude that one is better than the other. The difference could simply be due to the nature of the internet: you’ll never get exactly the same result.
But if one plugin has a median latency of 781 ms and another 862 ms, then the first one is indeed faster than the other. Keep in mind that a 100 ms difference on our server could represent a much larger difference on servers from less optimized providers.

The page we used for testing is an attempt to replicate a typical bloated page with the following elements:

A Contact Form 7 form.
A CookieYes cookie banner.
Text and images, inserted with Elementor.
The Hello Elementor theme.
A Prime Slider slider.
A TablePress table.
The following plugins activated: User Role Editor, Enable Media Replace, Simple Membership, WooCommerce y WP SVG Images.
A font from Google Fonts.

In addition, each caching plugin was tested under the following conditions:

WordPress 7.0 installed.
No optimization features enabled (minify CSS, JS, compress, etc.). We only want caching.
If the plugin offers it, we do not enable browser caching.
If the plugin offers it, we do enable Gzip compression. Some plugins have it enabled by default and cannot be disabled, so we try to standardize the conditions across all plugins.
We do not add any additional manual configurations to system files, such as Apache’s .htaccess or NGINX conf files. For example, it’s theoretically possible to increase the performance of Cache Enabler by manually adding a few code snippets, but this isn’t feasible for everyone and wouldn’t put all plugins on equal footing.
We do not enable mobile caching.
The browser is configured with the “Disable cache” option enabled so that all resources are requested from the origin server on each load, and a network preset of “Fast 4G” is used to minimize network variations and allow the browser to be the one limiting the loading speed.
All tests for each environment (Apache, NGINX, OpenLiteSpeed) are performed consecutively, on the same day/time, to try to eliminate network variations between different days.

And these are the versions of the cache plugins tested:

It’s also important to mention that we know this test may not be the most accurate in the world, but neither are online speed tests. It also represents reality in a way that’s closer to the actual user experience than many other posts or reviews that do not include concrete results, real numbers, or actual test data.

Final results

	Apache	NGINX	OpenLiteSpeed
Breeze	TTFB: 153 ms DOMCL: 1176 ms	TTFB: 92 ms DOMCL: 1064 ms	TTFB: 91 ms DOMCL: 977 ms
Cache Enabler	TTFB: 138 ms DOMCL: 1956 ms	TTFB: 79 ms DOMCL: 1066 ms	TTFB: 80 ms DOMCL: 974 ms
Comet Cache	TTFB: 160 ms DOMCL: 1178 ms	TTFB: 154 ms DOMCL: 1061 ms	TTFB: 158 ms DOMCL: 979 ms
Hummingbird	TTFB: 142 ms DOMCL: 1951 ms	TTFB: 85 ms DOMCL: 1054 ms	TTFB: 92 ms DOMCL: 974 ms
LiteSpeed Cache	N/A¹	N/A¹	TTFB: 60 ms DOMCL: 976 ms
Powered Cache	TTFB: 123 ms² DOMCL: 1121 ms	TTFB: 79 ms DOMCL: 1070 ms	TTFB: 60 ms DOMCL: 977 ms
SpeedyCache	TTFB: 132 ms² DOMCL: 1163 ms	TTFB: 76 ms DOMCL: 1077 ms	TTFB: 61 ms DOMCL: 978 ms
Super Page Cache	TTFB: 148 ms DOMCL: 1162 ms	TTFB: 141 ms DOMCL: 1066 ms	TTFB: 88 DOMCL: 977 ms
Swift Performance Lite	TTFB: 131 ms² DOMCL: 1164 ms	TTFB: 333 ms DOMCL: 1228 ms	TTFB: 62 ms DOMCL: 987 ms
W3 Total Cache	TTFB: 126 ms² DOMCL: 1950 ms	TTFB: 153 ms DOMCL: 1060 ms	TTFB: 61 ms DOMCL: 980 ms
WP Fastest Cache	TTFB: 132 ms² DOMCL: 1166 ms	TTFB: 669 ms DOMCL: 1559 ms	TTFB: 61 ms DOMCL: 978 ms
WP Rocket	TTFB: 157 ms³ DOMCL: 1165 ms	TTFB: 145 ms DOMCL: 1062 ms	TTFB: 90 ms DOMCL: 971 ms
WP Speed of Light	TTFB: 147 ms DOMCL: 1164 ms	TTFB: 83 ms DOMCL: 1066 ms	TTFB: 143 ms DOMCL: 986 ms
WP Super Cache	TTFB: 124 ms² DOMCL: 1953 ms	TTFB: 88 ms DOMCL: 1060 ms	TTFB: 62 ms DOMCL: 984 ms
WP-Optimize	TTFB: 140 ms DOMCL: 1174 ms	TTFB: 81 ms DOMCL: 1061 ms	TTFB: 139 ms DOMCL: 984 ms

¹ The LiteSpeed Cache functionality only works on LiteSpeed servers
² The plugin writes rules to the .htaccess file so that the cache file can be served directly without WordPress having to run PHP. The result is faster loading times.
³ WP Rocket adds rules to the .htaccess file in theory, but for some reason it doesn’t do so on this particular page, and therefore serves the cache by executing PHP code.

Apache

With Apache you can use the .htaccess file to change how the server responds to requests. In this file, you can write rewrite rules that tell the web server to serve cached web pages without requiring WordPress to process them. Remember that every time WordPress processes a page request, it has to execute PHP and make requests to the database, which is slower than if Apache served the page directly. Plugins can also write in this file, so cache plugins can offer two methods for serving the cache: through WordPress (executing PHP, which is slower) or through .htaccess (which is faster).

Knowing this, obviously all plugins that offer caching using the .htaccess file perform better than others. However, we haven’t included WP Fastest Cache, W3 Total Cache, or Swift Performance Lite in our list of best cache plugins. The first has a very poor interface and is quite limited in features, the second is one of the most complicated plugins out there to configure, and the third is practically abandoned.

Therefore, the best cache plugins for Apache are:

It’s interesting to note that a few plugins, for whatever reason, cause the DOMContentLoaded to almost double. This is why we haven’t included WP Super Cache in the list above, even though it achieves nearly the best TTFB.

Nginx

Nginx does not support the .htaccess file, and for cache delivery to behave the same way (i.e., for a page request to be handled just by Nginx), you would need to edit the Nginx conf files, which unfortunately plugins themselves cannot do. Therefore, you have to edit them manually. And the problem is that in most cases, unless you manage your own server, your hosting provider won’t allow it. So each plugin has to respond to the request by running PHP, which is how we really see the plugin’s performance; remember that if the server responds to the cache request instead of WordPress (as with the .htaccess file), the plugin virtually doesn’t even run.

Therefore, the best caching plugins for NGINX are:

If we had to choose, our #1 would be WP Super Cache, as it doesn’t have as cluttered an interface as Powered Cache or SpeedyCache, and it’s more flexible in terms of configuration than Cache Enabler, the other plugin without a custom interface.

Other plugins also achieve good results, but we’ve ruled them out for various reasons. You can read our opinion about each plugin below.

On the other hand, avoid both Swift Performance Lite and (especially) WP Fastest Cache. Both perform very poorly with Nginx.

OpenLiteSpeed

Finally, we reach OpenLiteSpeed. In terms of performance, OpenLiteSpeed is similar to LiteSpeed (which is a paid web server), although while LiteSpeed is 100% compatible with Apache’s .htaccess file, OpenLiteSpeed is not. Therefore, we can say that here we also see the true performance of each plugin: the server isn’t serving the cached pages, but rather WordPress running PHP.

Almost all plugins achieve here the same result, so considering all aspects, the best caching plugins for OpenLiteSpeed are:

And if we have to pick one, the best caching plugin for LiteSpeed/OpenLiteSpeed is, obviously, LiteSpeed Cache, simply because it’s made by the same people behind the LiteSpeed web server. This ensures seamless integration and the best load times, especially under heavy traffic.

Each cache plugin in detail

Breeze

This plugin was created by the Cloudways team. They obviously consider it the best plugin on the market, but the reality is that it doesn’t excel in any area.
Overly customized interface, far from WordPress standards.
It does offer some extra optimization options, but you’ll still need an additional frontend optimization plugin like Perfmatters if you truly want to optimize your website.

Cache Enabler

This is the plugin that should be the official WordPress cache plugin. It’s super small and lightweight, with no custom interface or unnecessary extra features, seamlessly integrating with the rest of the WordPress backend.
The problem is that results are mediocre on Apache and OpenLiteSpeed. Yes, you can improve it by serving the cache at the server level, via the .htaccess file, instead of running PHP. However, this isn’t suitable for everyone, and as we mentioned earlier, no files were manually edited in this test.
Not only that, but it significantly increases DOMContentLoaded on Apache.
It’s one of only two plugins that can’t change the WP_CACHE constant to true if it’s already set to false. Very annoying.
On Nginx, it’s almost the fastest!

Comet Cache

It scores the worst in Apache and OpenLiteSpeed, and its Nginx performance is simply mediocre.
There’s no shortcut in the top bar to clear the cache.
It has the ugliest, most confusing, and outdated interface of them all. It’s not worth it.

Hummingbird

The interface is also excessively customized, even childish, and has likely served as inspiration for Powered Cache (incomprehensibly). The problem is that they organize all the settings (not just for this plugin) in a way that makes it seem like there are 50 settings instead of 10. It’s clear they’re prioritizing appearance over results. In other words, selling.
Like almost all WPMU DEV plugins, its performance is merely average, and it suffers from the same problem as Breeze: its free version exists purely to sell you all their other services.
It’s because of this, but especially because we believe we shouldn’t support “advertising plugins,” where selling is more important than functionality, that we don’t think you should use this plugin, even though it performs well on Nginx (though not exceptionally well).
Just like with Cache Enabler, it significantly increases DOMContentLoaded on Apache.
At least it can preload the cache.
It has several page optimization options, but not enough to eliminate the need for a proper optimization plugin like Perfmatters.

LiteSpeed Cache

If your web server is LiteSpeed or OpenLiteSpeed, LiteSpeed Cache is the plugin to use, as the cache is served from the same server, without having to run PHP like most other plugins, which require running a minimum amount of PHP code.
Not only that, it integrates perfectly with QUIC.cloud, a free CDN (if you have low traffic) with HTTP/3 support that caches your pages at the edge (on the CDN servers), unlike most CDNs which only cache static resources (CSS, JS, fonts, images, and videos). In other words, with QUIC.cloud, your website will be lightning fast.
It offers many diverse and useful optimization features, such as copying external files locally (useful for not relying on external resources), critical CSS, removal of unused CSS, delaying JS execution, and more. You won’t need any other optimization plugins.
Like many others, it has a cache warm-up feature, so the cache is ready for all pages whenever it’s needed.
The interface is customized but not cluttered, and they manage to make each setting fairly clear.
The plugin can be a little tricky to configure for the average user, but it’s worth it on LiteSpeed servers, and there’s plenty of documentation available.
Make sure to read our articles on how to remove unnecessary menus or items from LiteSpeed Cache.

Powered Cache

Its interface is suspiciously similar to Hummingbird, which is bad. We would’ve loved seeing a vanilla interface here, because…
…it delivers almost the best results in all three environments. No matter what kind of website you have, the plugin will produce excellent results.
It includes some extra frontend optimization options, although the free version is a bit limited and forces you to rely on a more comprehensive optimization plugin.
It also includes a cache preloading feature, another great plus.

SpeedyCache

Another pleasant surprise on this list. Like Powered Cache, SpeedyCache works wonderfully in all environments.
It also has a somewhat cluttered interface, which is a bit off-putting, especially since the first thing you see on the first page of its settings is a performance score, similar to what PageSpeed Insights gives you, from 0 to 100. And we all know that the score is meaningless, what matters are the Core Web Vitals.
It also allows you to preload the cache.
It has some optimization options, but they’re not very useful in the free version; you’ll still need a plugin like Perfmatters. Ironic, considering the interface is clearly inspired by Perfmatters.

Super Page Cache

This plugin started out as Super Page Cache for Cloudflare, and initially it was simply a plugin that allowed you to cache HTML on Cloudflare for free. The plugin was a very good solution for using Cloudflare edge servers without paying a cent.
Today, the Cloudflare integration has taken a backseat, and the plugin is basically just another caching plugin.
Unfortunately, it delivers mediocre results in all environments.
Furthermore, its interface is too cluttered and customized, to the point that it has too many options and is more complicated to use than others.
Another drawback is that it always leaves traces in the .htaccess file after deactivation.
One of its few positive aspects is that it can preheat the cache.

Swift Performance Lite

Poor results on Nginx, but very good on Apache and OpenLiteSpeed.
The interface isn’t very polished (it’s rather ugly), the documentation isn’t very extensive, and the settings could be simplified a bit, but at least it’s not as bad as W3 Total Cache.
The Swift Performance Lite team hasn’t provided support or bug fixes for years (or at least that’s what can be understood from the changelog and the WordPress forum support page). It seems all their efforts are focused on the paid version. That’s why we can’t recommend the free plugin to anyone.
It’s one of the plugins that allows you to preload the cache, meaning you don’t have to wait for someone to visit a page for it to be cached, although you can configure it to do so.
It also includes many other website optimization features, such as minification and CSS/JS merging, and image optimization, but they aren’t very stable; there are better plugins for that. Swift Performance Lite is only meant to be used as a caching plugin.
Interface too customized.

W3 Total Cache

The popular W3 Total Cache, surprisingly, achieves one of the best TTFB scores on Apache and OpenLiteSpeed.
On Nginx, the results are mediocre.
On Apache, it increases DOMContentLoaded, as do other plugins, which means the plugin is only a good option on OpenLiteSpeed.
It has so many options, and they’re so complicated, even for expert users, that we can’t recommend it. Yes, it has a wizard, but with so many options, you always feel like there’s something that could be improved.
On the other hand, we appreciate that the author didn’t force their own interface in like most other plugins.
There are extra optimization options, but they also suffer from the same problem of being overly complicated to configure.

WP Fastest Cache

We don’t understand how this plugin is so popular: the interface is awful, the text is tiny, and it performs terribly on Nginx (the worst).
On the other hand, it works excellent on Apache and OpenLiteSpeed.
It’s very easy to configure. Just install it, activate the caching option, and you’re done.
It also has additional website optimization options, but many are paid, and even if you pay, you’ll still need a good optimization plugin if you really want to improve performance.
At least it can preload the cache.

WP Rocket

WP Rocket is currently the king of caching plugins. It’s the most popular and has the best support and documentation. Not only that, being the most famous, many other plugins develop their features with WP Rocket in mind.
It’s perhaps the most stable of all. Over all these years, it’s the one with the fewest bugs I’ve seen.
It’s not the fastest; in fact, it’s one of the slowest, but it tries to compensate for this with the aforementioned advantages.
Its interface is highly customized, but it’s not a cosmetic disaster.
It’s the only plugin on this list that isn’t in the WordPress plugin repository. In other words, it’s a paid plugin.
It has just the right amount of optimization features -not too many, not too few- and they work very well. Even so, you’ll need a plugin like Perfmatters if you want to do a proper optimization.
Like LiteSpeed Cache and others, it can preload the cache, and it does so in a less aggressive way than others, making it ideal for improving sites on cheap hosting that can’t handle much CPU work.

WP Speed of Light

A great surprise in terms of Nginx performance, although the interface is also quite cluttered and unpolished. If they polished the interface a bit, it could be a good plugin to consider.
It doesn’t stand out in any way on Apache or OpenLiteSpeed.
Many optimization options, but limited in the free version.

WP Super Cache

Some might call it the “official” WordPress cache plugin because it’s developed by Automattic, who also owns WordPress.com.
We’re quite surprised by its performance. Along with Powered Cache and SpeedyCache, it’s the only plugin that consistently delivers excellent results across all three web servers. It’s clear this plugin comes with only the essentials and is well-programmed. However, you do need to enable “Expert” mode in its settings for the cache to work as fast as possible.
However, we can’t recommend it for Apache because it increases DOMContentLoaded.
We don’t like that by default, if you don’t adjust any settings, the time it takes for cached pages to be cleared isn’t long enough (only 30 minutes by default, which means that on low-traffic sites, there will almost never be anything cached).
On the other hand, its interface is very clean, except for the Jetpack ads, and it’s relatively easy to use. It obviously adheres to WordPress design standards.
It can preload the cache.
Overall, it’s the plugin I’d recommend for anyone who wants something cheap and cheerful.

WP-Optimize

This plugin was originally used for database cleaning, which it does very well. But it seems the surprise feature is page caching. It’s very easy to configure: just activate an option and you’re done. A perfect plugin for beginners. It also performs quite well, but only on Nginx. On the other two environments, it’s mediocre.
There’s little flexibility regarding exclusions or cache configuration.
However, it does at least have the option to preload the cache.
The interface is customized, but not excessively so; it maintains a good balance. We’d prefer it to be more like WP Super Cache or Cache Enabler.

Conclusion

If we had to choose three plugins to always recommend, considering performance, ease of use, stability, and support, they would be: Powered Cache, SpeedyCache and WP Super Cache. And if you use LiteSpeed or OpenLiteSpeed, add LiteSpeed Cache to the list.

It’s also interesting to see how rare it is for a plugin to have an uncustomized interface, following WordPress guidelines. We understand that every plugin wants to stand out, and one way they do this is by introducing their own design. But the drawback is that it forces more CSS and JS code to load in the back-end, slowing down the loading of the plugin settings page and introducing more confusion, especially for non-expert users who expect the entire back-end to have a single, consistent interface.

It’s important to remember that every website is unique, and results may vary depending on the configuration and components present on each page. However, this experiment has given us a realistic and practical insight into which caching plugins are the most efficient and easy to use.

We hope this article was helpful and will help you make an informed decision about which caching plugin to use on your WordPress website. Until next time!

Appendix

This is the script used to calculate the TTFB and DOMContentLoad, automatically reload the page 20 times, and then calculate the median:

const runs = 20;
const delay = 5000;

let data = JSON.parse(sessionStorage.getItem("perfRuns") || "[]");

const nav = performance.getEntriesByType("navigation")[0];

const ttfb = nav.responseStart - nav.requestStart;
const domCL = nav.domContentLoadedEventEnd - nav.startTime;
const load = nav.loadEventEnd - nav.startTime;

data.push({ ttfb, domCL, load });
sessionStorage.setItem("perfRuns", JSON.stringify(data));

console.log(`Run ${data.length}:`, { ttfb, domCL, load });

const median = arr => {
  const sorted = [...arr].sort((a, b) => a - b);
  const mid = Math.floor(sorted.length / 2);
  return sorted.length % 2
    ? sorted[mid]
    : (sorted[mid - 1] + sorted[mid]) / 2;
};

if (data.length < runs) {
  setTimeout(() => location.reload(), delay);
} else {
  const medianTTFB = median(data.map(x => x.ttfb));
  const medianDOM = median(data.map(x => x.domCL));
  const medianLoad = median(data.map(x => x.load));

  console.table(data);
  console.log("Median TTFB:", medianTTFB);
  console.log("Median DOMContentLoaded:", medianDOM);
  console.log("Median Load:", medianLoad);

  sessionStorage.removeItem("perfRuns");
}