If you are choosing between LiteSpeed Cache, WP Rocket and nginx FastCGI cache, the honest answer is that the plugin name matters far less than one thing: whether a cached page is handed to the visitor by the web server, or by PHP. Get that right and all three land within a few tens of milliseconds of each other on TTFB. Get it wrong and the best plugin on the market will still run WordPress on every single request.
That is why most “LiteSpeed vs WP Rocket” comparisons you will find are not measuring what they think they are measuring. They install plugin A on a LiteSpeed host, install plugin B on the same host, run PageSpeed Insights once each, and report the score. What they have actually compared is one plugin that is being served by the web server and one that may or may not be, on a sample size of one, with no baseline.
Below is what each layer does at the request level, and a benchmark method that will not lie to you.
The short answer: which one is faster?
On a correctly configured server, the ranking on cache-hit TTFB is:
- Nginx FastCGI cache and LiteSpeed Cache on a LiteSpeed server — effectively tied. The web server reads the cached response and returns it. PHP is never started.
- WP Rocket with its rewrite rules active — very close behind. Apache (or nginx with the WP Rocket config) serves a static HTML file from disk without loading WordPress.
- WP Rocket without those rewrite rules — materially slower. The request goes nginx → PHP-FPM → PHP → static file. WordPress boots, reads the cache file, and prints it. You still get a cached page, but you pay for a PHP worker to deliver it.
- LiteSpeed Cache on Apache or nginx — no page cache at all. The plugin’s optimisation features work, but the caching features do not, because they depend on the server’s built-in LSCache.
That last point catches people out constantly. LiteSpeed Cache has over 7 million active installs, and a good share of those sites are on Apache or nginx, where the one feature everyone installed it for is inert.
What happens when a visitor hits a cached page
This is the whole argument, so it is worth being precise about it.
| Setup | Request path on a cache hit | PHP started? |
|---|---|---|
| LiteSpeed Cache + LiteSpeed/OpenLiteSpeed server | Server → LSCache → response | No |
| LiteSpeed Cache + QUIC.cloud CDN (any server) | CDN edge → response | No (origin not touched) |
| LiteSpeed Cache + Apache or nginx, no CDN | No page cache — full WordPress request | Yes, every time |
| Nginx FastCGI cache | nginx → cache file → response | No |
WP Rocket + .htaccess rules (Apache) | Apache rewrite → static HTML → response | No |
| WP Rocket + nginx, with WP Rocket’s nginx config | nginx → static HTML → response | No |
| WP Rocket + nginx, no config applied | nginx → PHP-FPM → PHP → static HTML | Yes, every time |
WP Rocket’s own documentation is explicit about this: cached pages are served either by rewrite rules in .htaccess (or the WP Rocket nginx configuration), or by PHP files when those rules are absent. The widely used Rocket-Nginx helper project exists precisely because, by default on nginx, “WP-Rocket executes PHP even when a file is in cache.”
The practical consequence is not the 20–80 ms of TTFB. It is PHP worker capacity. A site serving cache hits through PHP occupies a worker for every page view, so a traffic spike queues at PHP-FPM. A site serving cache hits from the web server does not. That is the difference between a page that gets slower under load and one that does not — and it is invisible in a single PageSpeed run on an idle site. If you have ever wondered why a site with good lab scores still feels sluggish for real visitors, this is one of the usual culprits; we went through the others in why your PageSpeed score is 95 and your site still feels slow.
LiteSpeed Cache: free, excellent, and tied to your host
LiteSpeed Cache (version 7.9.1 at the time of writing, WordPress 6.0+ and PHP 7.4+) is the most capable free caching plugin available, and on LiteSpeed hosting it is hard to beat. The plugin’s own listing splits its features into two groups: general features that work on any server, and “LiteSpeed Exclusive” features that require OpenLiteSpeed, a commercial LiteSpeed product, LiteSpeed-powered hosting, or the QUIC.cloud CDN. Automatic page caching sits in the exclusive group.
So the decision tree is short. On LiteSpeed hosting, use it — you get server-level caching, ESI for hole-punching dynamic fragments, and crawler-based cache warming, for nothing. On Apache or nginx, your options are QUIC.cloud (free tier available, paid above certain usage, and it processes your pages at the edge) or a different plugin. Installing it on nginx and leaving it at that gets you optimisation features and no cache.
The trade-off nobody mentions: tying caching to your host is a migration cost. Move off LiteSpeed and the configuration does not come with you.
WP Rocket: portable, paid, and only as fast as its rewrite rules
WP Rocket currently starts at $4/month billed yearly for a single site, $8/month for three, and $20/month for the multi-site tier, with a 14-day trial; the licence renews annually at the regular price to keep updates and support. It caches on any server, which is the entire point of it.
It writes each cached page to disk under /cache/wp-rocket/your-domain.com/, with separate files per variant — index-https.html, a gzip copy, index-mobile-https.html when mobile cache is on, WebP variants, and cookie-specific versions when dynamic cookies are in play. That variant explosion is worth knowing about: every extra dimension (mobile, WebP, logged-in cookie) multiplies the number of files that must be generated and warmed, and dilutes your cache hit ratio.
If you run WP Rocket, the single highest-value thing you can do is confirm the rewrite rules are actually in place. On Apache, look for the WP Rocket block in .htaccess. On nginx, confirm the WP Rocket nginx configuration has been applied; if it has not, you are paying for a cache that PHP is delivering.
If you are not sure which path your cache hits are taking, that is a 20-minute check — send us the URL and we will tell you whether the web server or PHP is answering, and what it is costing you.
Nginx FastCGI cache: the fastest hit path, the worst purge story
FastCGI cache is built into nginx. No plugin, no licence, and the cache hit never touches PHP. A minimal working configuration looks like this:
fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
map $http_cookie $skip_cache_cookie {
default 0;
~*comment_author 1;
~*wordpress_logged_in 1;
~*wp-postpass 1;
~*woocommerce_items_in_cart 1;
}
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_valid 404 1m;
fastcgi_cache_bypass $skip_cache_cookie $arg_nocache;
fastcgi_no_cache $skip_cache_cookie $arg_nocache;
fastcgi_cache_use_stale error timeout updating http_500 http_503;
add_header X-FastCGI-Cache $upstream_cache_status;
}Three details that matter more than the rest:
keys_zonesizing. Per nginx’s documentation, one megabyte of zone stores roughly 8,000 keys. A 100 MB zone therefore covers around 800,000 cached URLs — far more than most sites need, and cheap in RAM.inactivedefaults to 10 minutes, not the value infastcgi_cache_valid. Anything not requested within that window is evicted regardless of freshness. On a site with a long tail of low-traffic pages, leaving it at the default means most of your catalogue is permanently cold. Set it well above your traffic interval.fastcgi_cache_use_stale ... updatingis what stops a thundering herd when a popular page expires: one request regenerates it while everyone else is served the stale copy.
The catch is purging. Stock open-source nginx has no selective purge. The Nginx Helper plugin (2.4.1, 200,000+ installs) exists to purge on publish and edit, but it requires the third-party ngx_cache_purge module compiled into nginx — its own documentation says it “will not work out of the box.” Nginx’s native purger parameter is commercial-subscription only. If you cannot rebuild nginx or install a prebuilt module, your realistic options are short TTLs or full-cache flushes, and WooCommerce sites in particular will feel that.
Side-by-side
| LiteSpeed Cache | WP Rocket | Nginx FastCGI cache | |
|---|---|---|---|
| Cost | Free (QUIC.cloud paid above free tier) | From $4/mo, 1 site, billed yearly | Free |
| Server requirement | LiteSpeed/OpenLiteSpeed, or QUIC.cloud CDN | Any | nginx |
| Cache hit bypasses PHP | Yes, on LiteSpeed | Only with rewrite rules applied | Yes |
| Selective purge on publish | Yes, built in | Yes, built in | Needs ngx_cache_purge + Nginx Helper |
| Logged-in / cart exclusions | UI, plus ESI hole-punching | UI | Hand-written cookie map |
| Cache warming | Built-in crawler | Preload | None (script it yourself) |
| Who maintains it | Plugin, self-serve | Plugin, self-serve | You or your host, at server level |
| Survives a host migration | No | Yes | No |
How to benchmark all three on the same site
A comparison is only worth something if the two runs differ in exactly one thing. Most published ones differ in four. Here is a method that holds up:
- Measure TTFB, not a score. PageSpeed Insights conflates server response with render work and third-party scripts; caching mostly moves one of those. Use
curl -w "%{time_starttransfer}"against the same URL, or a synthetic monitor that reports TTFB separately. - Take at least 20 runs per configuration and report the median plus the 95th percentile. Single-run numbers on shared hosting have variance wider than the effect you are trying to measure. The 95th percentile is where cache misses and PHP queueing show up.
- Measure three states, not one: cold cache, warm cache, and logged-in. The warm number is the marketing number. The cold number is what a crawler or a long-tail visitor gets, and the logged-in number is what your client experiences all day.
- Confirm you are actually hitting cache. Check
x-litespeed-cache: hit, WP Rocket’s HTML footer comment, orX-FastCGI-Cache: HIT. Many “the cache made no difference” results are simply misses. - Keep a no-cache baseline. Without it you cannot separate a 40 ms gap between plugins from the 400 ms gap against no cache at all — and the second number is the one that matters.
- Test under concurrency. Run
ab -n 500 -c 20or similar. This is where the PHP-versus-server question stops being academic: a server-served cache holds flat, a PHP-served cache climbs. - Change one variable at a time. Swapping the cache while also enabling minification and a CDN tells you nothing about the cache.
Also measure cache hit ratio over a week, not latency on one URL. A cache that is 40 ms faster per hit but drops the hit ratio from 90% to 60% — because of mobile, WebP and cookie variants — is a net loss. On WooCommerce the exclusions do most of the damage, since cart, checkout and account pages are uncacheable by definition.
What the numbers usually show
Run honestly, same-site comparisons tend to land in the same place. Between any two correctly configured server-level caches, the gap on warm TTFB is small enough that it is not a reason to switch. The large, reliable differences are elsewhere: no cache versus cache, server-served versus PHP-served, and high hit ratio versus low. Teams routinely spend weeks choosing between plugins and then leave the rewrite rules unapplied, or set inactive to the 10-minute default, and lose more than the choice ever gained them.
Caching also will not fix work that happens after the HTML arrives. If your Largest Contentful Paint is poor because of an oversized hero image, or your Interaction to Next Paint is poor because of JavaScript, a faster cache hit moves neither; the “good” thresholds Google assesses at the 75th percentile are 2.5 s for LCP, 200 ms for INP and 0.1 for CLS, and only the loading side of that is a server concern. We covered that split in Core Web Vitals in 2026, and the page-builder overhead that often dominates it in the hidden cost of page builders.
So which one should you run?
- On LiteSpeed hosting: LiteSpeed Cache. It is free, it is server-level, and anything else is a downgrade.
- On Apache, or managed hosting where you do not control the server: WP Rocket, with the rewrite rules verified.
- On nginx with root access: FastCGI cache, provided you can install
ngx_cache_purge. If you cannot, WP Rocket with the WP Rocket nginx configuration is the better trade. - On nginx without root and without the WP Rocket nginx config: you have the worst case of the lot. Fix the serving path before you fix anything else.
The cache layer is also only one of several reasons a site responds slowly; the full list of what we find on first inspection is in why your WordPress site takes 8 seconds to load.
If you would rather not run twenty curl loops across three configurations yourself, we will benchmark your site properly — cold, warm, logged-in and under load — and tell you whether your current cache is doing its job or whether PHP is quietly answering every request. Most of the time the fix is a configuration change, not a new plugin.