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

> W3 Total Cache, WP Super Cache and WP Fastest Cache measured on CorePanel next to its own page cache: all four take an Elementor page from 437 ms to 2–10 ms.

Source: https://www.corepanel.net/blog/wordpress-cache-plugins-on-corepanel
Author: CorePanel Team
Published: 2026-11-06
Tags: performance, wordpress, caching, benchmark
From the CorePanel blog — https://www.corepanel.net/blog

---

> **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](https://www.corepanel.net/blog/elementor-cache-webp-http3):

| | |
|---|---|
| **Server** | 2 vCPU, 3.5 GB of RAM, AlmaLinux 8 |
| **Site** | The `agency` profile of [`wp-test`](https://github.com/pyxsoft/wp-test): Elementor, 30 builder pages, **254 KB of HTML** per page |
| **What we timed** | A builder page, 50 requests over one reused connection, median (p50) |
| **Held constant** | Early Hints and WebP off in every pass, so only the cache changes |
| **One at a time** | One cache active per pass, each plugin on its disk cache setting |

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

## The result

| | Builder page, p50 | Served by |
|---|---|---|
| No page cache | 437.3 ms | PHP builds the page |
| **CorePanel page cache** | **2.0 ms** | Web server, from memory |
| **W3 Total Cache** (Disk: Enhanced) | **2.3 ms** | Web server, from disk |
| **WP Super Cache** (Expert) | **3.0 ms** | Web server, from disk |
| **WP Fastest Cache** | **9.8 ms** | Web server, from disk |

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](https://www.corepanel.net/docs/web/htaccess#caching-plugins-keep-working).
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:

```apache
<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](https://www.corepanel.net/pricing); see
  [how it works](https://www.corepanel.net/docs/web/optimizations).

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`](https://github.com/pyxsoft/wp-test),
so anyone can reproduce it:

```bash
# 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](https://www.corepanel.net/blog/elementor-cache-webp-http3) takes the same site to 400
simultaneous visitors.