Enable LSCache for WordPress on a cPanel server

LSCache is the reason most hosts switch from Apache to LiteSpeed. It's a server-level page cache that sits inside the LiteSpeed binary — not a PHP plugin emitting headers, not Varnish in front. On a typical WordPress site, that's the difference between 80-150 ms TTFB and 8-20 ms TTFB, and roughly a 10× drop in PHP-FPM workers needed at peak.

This guide covers the WHM-side mass deployment (so you don't install the plugin on 200 accounts one at a time), the per-site activation step that owners still need to do, and the three configurations that quietly disable the cache: WooCommerce carts, logged-in sessions, and cookie-based personalisation.

Prerequisites

You need LiteSpeed Web Server running on the cPanel box, not Apache. If you're still on Apache, walk through installing LSWS on a cPanel box first — LSCache requires LSWS as the web server, it won't work on top of stock Apache.

You also need:

• WHM root access
• The LiteSpeed WHM plugin (installed automatically with LSWS)
• An active LSWS licence — LSCache is bundled, no separate licence needed

Confirm LSWS is serving traffic:

curl -I https://anysite.example/ | grep -i server

You should see Server: LiteSpeed. If not, stop here — the cache layer won't engage.

Step 1 — Auto-install the LiteSpeed Cache plugin fleet-wide

In WHM → LiteSpeed Web Server → WordPress Cache Manager, click Scan. The plugin walks /home/*/public_html and every addon-domain document root, fingerprints WordPress installs, and reports back with three columns:

• WordPress installs found — total count detected
• LSCache plugin installed — sites that already have the plugin
• Cache enabled — sites where the plugin is installed and activated

Click Enable on all to install and activate the LiteSpeed Cache plugin on every detected install. Behind the scenes this drops the plugin into wp-content/plugins/ and activates it via WP-CLI as the owning cPanel user (not as root — file ownership is preserved).

On a server with 150 WordPress installs, the scan takes 30-90 seconds and the mass-enable takes 2-4 minutes.

Step 2 — Set sensible defaults on the cache itself

The plugin's default settings work, but two non-default values save real CPU.

In WHM → LiteSpeed Web Server → LSWS Configuration → Cache Settings (server context):

• Enable Cache — 1
• CheckPublicCache — 1
• CheckPrivateCache — 1
• Max Object Size — 10000000 (10 MB; default 1 MB drops large pages out of cache)
• Max Cache Age — 604800 (7 days, up from default 1 day; the plugin invalidates on post update anyway)
• Storage Path — /usr/local/lsws/cachedata/ (default; just confirm the partition has 10+ GB free)

Save and click Graceful Restart. No traffic is dropped — workers cycle one at a time.

Step 3 — Verify cache hits on a sample site

Pick any WordPress site on the server and request a public page twice:

curl -I https://samplesite.example/
curl -I https://samplesite.example/

The second response should include:

x-litespeed-cache: hit

The first will show miss. If both show miss, the page isn't being cached. Common reasons, in order of frequency:

1. A cookie marks the request as private. Logged-in users, ecommerce carts, and wp-admin traffic are excluded from the public cache by design. Test as a logged- out anonymous visitor.
2. A query string is breaking the cache key. UTM parameters (?utm_source=...) default to busting cache. Configure them as cacheable under Cache → Browser → Excludes in the per-site plugin settings.
3. A Cache-Control: no-cache header is set elsewhere. Check .htaccess for leftover Apache cache rules, and any security plugin that aggressively sets no-cache headers.

Step 4 — Configure for WooCommerce and logged-in traffic

If any site on the server runs WooCommerce, BuddyPress, LearnDash, or any other plugin that needs per-user state, you need the ESI (Edge Side Includes) settings. LSCache can cache the page shell publicly while punching holes for cart counts, greeting messages, and other per-user fragments.

Per-site, in the WordPress admin → LiteSpeed Cache → Cache → ESI:

• Enable ESI — ON
• Cache Admin Bar — OFF
• Cache Comment Form — ON
• ESI Nonce — leave default plus add any plugin-specific nonces in the textbox

For WooCommerce specifically, ensure the LiteSpeed Cache plugin's WooCommerce section has Product Update Interval set to Purge product on changes that affect the product page and Use Front Page TTL for the Shop Page is on.

Without ESI, every page on a WooCommerce site is treated as private and never enters the public cache — you'll see your cache hit ratio sit near zero.

Step 5 — Monitor cache hit ratio

WHM → LiteSpeed Web Server → Real-Time Statistics shows a Cache Hit Rate line. Healthy values:

• Static asset cache hit rate — should be 95%+ within an hour
• Public page cache hit rate — should be 60-85% on a typical content site, 30-50% on an ecommerce site, 10-30% on a heavily personalised site

If public cache hit rate stays under 10% on a content site after a day of traffic, you have a misconfiguration — almost always cookies, query strings, or a security plugin emitting Cache-Control: no-store.

Common gotchas

• CloudLinux LVE interaction: LSCache hits don't consume entry processes (EP), so caching dramatically lowers EP pressure on heavy WordPress users. If you tuned LVE limits before enabling LSCache, revisit them — most operators can tighten EP by 50% post-cache.
• Jetpack and other CDN integrations: If a site is fronted by Jetpack's CDN, the origin LSCache only sees CDN-cache misses. The hit rate looks low at origin even when the user experience is fast.
• Cron-based purges: WordPress emits cache purges on post update. If a site has WP-Cron disabled and uses an external cron, ensure that cron is firing — stale cache is the symptom.

Next steps

• If LSWS isn't installed yet, start with installing LSWS on a cPanel box.
• Pair LSCache with CloudLinux to cap heavy users — see CloudLinux LVE tuning without angry customers.
• Still deciding between the paid and free LiteSpeed editions? Read LiteSpeed Web Server vs OpenLiteSpeed for cPanel hosting.