Setting up the LiteSpeed Cache plugin in WordPress

LSCache is LiteSpeed’s page cache — and it works at a different layer than the usual WordPress caching plugins. WP Super Cache, W3 Total Cache and friends assemble finished pages in PHP and store them as files; PHP still has to spin up on every request. LSCache sits directly in the web server: if a page is in the cache, LiteSpeed serves it before PHP even starts. That’s the difference between a few hundred milliseconds and a double-digit millisecond time-to-first-byte.

The LiteSpeed Cache plugin (LSCWP for short) is the control center for all this in WordPress: it tells the web server which pages to cache for how long, and when to rebuild them. Our LiteSpeed Web Hosting runs on LiteSpeed Enterprise — so the plugin connects on its own, no license key, no extra configuration. In this article we set it up together.

Preparation: old caching plugin out

By far the most common cause of LSCache trouble is a second caching plugin still running in parallel. Two page caches stacked on top of each other mean duplicate purge logic, stale content and, in the worst case, white pages. So before installing:

1. Deactivate and delete the old caching plugin (WP Rocket, W3 Total Cache, WP Super Cache, WP Fastest Cache, Cache Enabler …) — don’t just deactivate it.
2. Check for leftovers: the file wp-content/advanced-cache.php and the line define('WP_CACHE', true); in wp-config.php often still belong to the old plugin. Clean uninstalls remove them — in practice, something tends to stick around.
3. Pure optimization plugins (Autoptimize for CSS/JS, image compressors) can stay. Just no second page cache.

In our experience, this one step prevents the majority of later tickets before they happen.

Install the plugin

In the WordPress admin: Plugins → Add New, type “LiteSpeed Cache” into the search field. The official plugin comes from “LiteSpeed Technologies” and has several million active installations. Install Now, then Activate.

That’s all it takes. The plugin automatically detects that it’s running on a LiteSpeed server and talks directly to the web server — no API key, no license field, no mandatory wizard. Whether the connection is up you can see under LiteSpeed Cache → Dashboard: if there’s no warning that no LiteSpeed server was detected, everything is fine. On our hosting it doesn’t appear.

Recommended base settings

Enable the cache

Under LiteSpeed Cache → Cache, tab Cache: the Enable Cache switch is already ON after installation — checking once doesn’t hurt anyway. Leave the sub-options (cache logged-in users, commenters, REST API) at their defaults.

Understand the TTLs and leave them alone

TTL (Time to Live) defines how long a cached page counts as fresh. The TTL tab holds the defaults — public pages long, private content much shorter. You can leave these defaults as they are: LSCache cleans up specifically on every content change anyway. When you save a post, the plugin automatically purges the post itself, the front page and the affected archives. The TTL only acts as an upper limit for pages that never change on their own.

The only adjustment worth making at the start: if your front page shows externally embedded content WordPress knows nothing about, lower the front page TTL to a few hours.

What you don’t touch at the start

The plugin can do a lot more than cache pages — and that’s exactly where you buy yourself trouble by switching everything on at once:

• Page Optimization (minify and combine CSS/JS): later, switch by switch, with a test after every single one. Combined CSS/JS is the classic cause of broken layouts.
• Image optimization and CDN (QUIC.cloud): needs an external account, unnecessary for the start.
• Crawler: leave it off — it pre-warms the cache, but costs resources.
• ESI: powerful (caching individual page fragments separately), but a topic for later.

The order that has proven itself with us: run nothing but the page cache for a week first, then add optimizations one by one as needed.

Purging the cache

Three ways:

• Admin bar: the LiteSpeed icon at the top → Purge All. The fastest route after theme or CSS changes.
• Automatic: when you save content, the plugin purges the affected pages itself — nothing for you to do.
• Via WP-CLI over SSH (included in every plan with us):

wp litespeed-purge all

Handy for deployments: append the command to the end of your deploy script, done.

Verifying success: x-litespeed-cache: hit

The response header tells you whether the cache is kicking in. From your own machine:

curl -I https://deine-domain.de/

On the first request, the response contains:

x-litespeed-cache: miss

The page was freshly built and stored in the cache along the way. On the second request:

x-litespeed-cache: hit

That’s the goal. Alternatively in the browser: open DevTools (F12) → Network → reload the page → click the first entry → look at the response headers. Important: test in a private window, not logged in — why, see right below.

Typical pitfalls

Logged-in users don’t see the cache

By default, LSCache only caches anonymous visitors. As long as you’re logged into WordPress (admin bar visible), you get miss or no cache header at all — that’s intentional, not broken. The typical pitfall: test while logged in, see miss, spend hours hunting a bug that doesn’t exist. Always check in a private window or via curl.

Leftovers from the old caching plugin

Symptoms: stale content despite purging, or the x-litespeed-cache header missing entirely. In 95% of cases a foreign advanced-cache.php is still sitting in wp-content/, or the old plugin is merely deactivated instead of deleted. Clean up as described above, then Purge All.

Pages with visitor-specific content

The plugin detects WooCommerce on its own and automatically excludes cart and checkout from the cache. If another plugin serves different content per visitor (geo banners, currency switchers), exclude the affected page from the cache under Cache → Excludes — otherwise visitors see each other’s variants.

Frequently asked questions

Do I really have to uninstall WP Rocket even though I paid for it? Yes. Two page caches in parallel break more than they speed up. LSCache works inside the web server and is structurally superior to PHP-based solutions — you can keep using your WP Rocket license for projects on other hosts.

The header only ever shows miss — now what? First check whether you’re logged in (use a private window). Then: is the page excluded? Search results and the cart are never cached. Is an old advanced-cache.php still sitting in the wp-content folder? If it’s still stuck after that: open a ticket at mein.xaweho.de/kontakt and we’ll look at the headers with you.

Can LSCache also cache logged-in users? It can (private cache, ESI) — but that’s advanced territory. For the start: no, and for most sites that’s exactly right. Visitors get the turbo, editors always see the live state.

Does the plugin work with other hosts too? Only if an actual LiteSpeed server runs there. On Apache or nginx a few optimization features stay usable, but the actual page cache — the core of the whole thing — stays dead.

Will you migrate my WordPress site and set up LSCache while you’re at it? Yes, we handle the migration for a flat fee via ticket — the price is on the product page. We enable LSCache as part of it and measure afterwards.

What’s next

• WordPress Toolkit in Plesk — staging, cloning, updates from one interface
• Migrating WordPress to xaweho — if your site still lives elsewhere
• LiteSpeed Web Hosting — plans, specs and what else is included