Your WordPress cache plugin on CorePanel: 437 ms down to 2 ms

In short: we put the three most common free WordPress page caches — W3 Total Cache, WP Super Cache and WP Fastest Cache — on a CorePanel server, one at a time, next to CorePanel’s own page cache. An Elementor page that takes 437 ms to build came back in 2.0 ms from CorePanel’s cache, 2.3 ms from W3 Total Cache, 3.0 ms from WP Super Cache and 9.8 ms from WP Fastest Cache. All three plugins are served by the web server straight from disk, without starting PHP. If your site already runs one of them, it keeps working on CorePanel, and it is fast.

Most WordPress sites that move to a new server bring a cache plugin with them. It was installed years ago, it was tuned once, and it works. So the first question a site owner asks about a new panel is not whether the panel has a better cache. It is whether the one they already have will keep working.

On CorePanel it does, and we measured how well.

The setup

The same server and site as our Elementor measurements:

The measurements were taken on 13 August 2026, with CorePanel’s own cache off while each plugin ran.

The result

Every cache did its job: from 437 ms to a handful of milliseconds, between 45 and 220 times faster. The gap between the fastest and the slowest is under 8 ms, which a visitor will not notice next to the time the page spends on the network.

Why the plugins are this fast here

A disk cache plugin writes a finished copy of each page to a file, and then writes rules into the site’s .htaccess that send a visitor straight to that file. On Apache those rules are what make the plugin fast: PHP and WordPress never start.

CorePanel’s web server, corehttpd, reads those same rules. None of the three plugins needed a setting changed to run on it. W3 Total Cache even runs its own check of the rewrite setup (wp total-cache fix_environment), and it passes: “Environment adjusted”. The responses show that PHP was never reached.

What the last few milliseconds depend on

The ranking between the plugins comes from one decision each plugin makes: does it store the page already compressed?

W3 Total Cache and WP Super Cache store two copies of each page, plain and gzipped, and declare in the .htaccess what the compressed one is:

<IfModule mod_mime.c>
    AddType text/html .html_gzip
    AddEncoding gzip .html_gzip
</IfModule>

With those two lines the server hands the stored compressed bytes to the browser untouched. There is no work left to do on the request, which is why they come within a fraction of a millisecond of a cache held in memory.

WP Fastest Cache stores only the plain page — 254,266 bytes here — and the server compresses it on every request, down to 41,730 bytes on the wire. That compression is the difference between 3 ms and 10 ms. It is not a weakness of the plugin: any server that compresses its pages does the same work for it. (WP Fastest Cache also asks Elementor to print its CSS inline; that accounts for 849 bytes of the page, not for the time.)

One difference in behaviour is worth knowing. WP Super Cache also caches search results: /?s=… came back in 6.1 ms instead of 430, and the stored result is served to the next visitor who searches for the same thing. CorePanel’s cache and the other two plugins send every search to WordPress. For a site whose search results are the same for everyone that is a free speed-up, so check what your site’s search shows before you rely on it.

A plugin or CorePanel’s cache: both are good choices

The numbers say it plainly: a well-configured cache plugin is as valid a choice on CorePanel as our own cache. Pick the one that suits the site:

• Keep your plugin if it is already set up and the site is happy with it. It works from the first request after the move, it travels with the site wherever it goes next, and .htaccess support is in every edition of CorePanel, including the free Personal one. A Personal server running W3 Total Cache or WP Super Cache serves pages within a millisecond of the Pro cache.
• Use CorePanel’s page cache if you would rather not configure a plugin per site. It is switched on from the panel, it keeps pages in memory, and a small companion plugin tells it which pages may be shared (logged-in visitors, carts and checkouts never are). It is part of the Speed Optimizer in CorePanel Pro; see how it works.

What you should not do is run both. Two page caches on one site fight over the same output, so CorePanel’s cache steps aside on its own when it sees a page cache plugin active. If you do switch to ours, turn off only the plugin’s page cache and keep the rest: object caching, minification and CDN settings in W3 Total Cache and its peers are still worth having, and WooCommerce’s cart and admin lean on the object cache.

Measure it yourself

The site is rebuilt from a fixed seed by wp-test, so anyone can reproduce it:

# On the server under test, as the site's own user:
git clone https://github.com/pyxsoft/wp-test.git && cd wp-test
./build.sh --profile agency --path ~/public_html --url https://example.com \
           --db-name wp_bench --db-user wp_bench --db-pass 'secret'

Install one plugin, enable its disk cache, warm a page, and time it. Then do the same with the next one. If you want to see how far the cache goes under load rather than per page, the Elementor post takes the same site to 400 simultaneous visitors.