LiteSpeed Cache WordPress cPanel: Recommended Settings

The plugin has 200 options and most defaults are right. These are the twelve that decide whether you get a 50 ms TTFB or a broken checkout, and how to prove the cache is working.

Published 29 Sep 2026Updated 3 Oct 2026 4 min read By srvScripts team

What has to be true on the server

LiteSpeed Cache (LSCWP) only does page caching when the web server is LiteSpeed Enterprise or OpenLiteSpeed. On cPanel with Apache, the plugin still runs (image optimisation, CSS/JS tweaks) but every page is a cache miss. Check from any page:

curl -sI https://example.com/ | grep -Ei 'server|x-litespeed-cache'

You want server: LiteSpeed and, after the second request, x-litespeed-cache: hit. If the header says miss every time, the server-level cache is not enabled for the account: in WHM → LiteSpeed Web Server → Configuration, confirm Cache Storage Path is set and that the account’s .htaccess contains the <IfModule LiteSpeed> block the plugin writes. If the plugin cannot write .htaccess, that block is missing — fix permissions or paste it from LiteSpeed Cache → General → the yellow notice.

Cache settings (LiteSpeed Cache → Cache)

Enable Cache: ON. Cache Logged-in Users: OFF. Logged-in caching is for membership sites with private cache and needs care; for most sites it just wastes disk.
Cache Commenters: OFF, Cache REST API: ON, Cache Login Page: ON, Cache Mobile: OFF unless the theme serves different HTML to phones (AMP or a separate mobile theme). A responsive theme sends the same HTML, so a separate mobile cache only halves your hit rate.
TTL: Default Public Cache TTL 604800 (a week), Front Page TTL 604800, Feed TTL 604800, 404 TTL 3600. Long TTLs are safe because LSCWP purges on every post save, comment, and WooCommerce stock change; a short TTL just means more misses.
Purge → Auto Purge Rules: leave the defaults, and tick Purge All On Upgrade. Add Scheduled Purge URLs only for pages that show external data (a price feed, a stock ticker).
Excludes: add /cart/, /checkout/, /my-account/ for WooCommerce (the plugin does this automatically when Woo is active, but check), plus any page with a form that shows a nonce error when cached. Exclude the cookie wordpress_logged_in_ if you enabled logged-in caching by mistake.
ESI: OFF unless you know why you need it. It lets you cache a page with a dynamic cart widget, but with private ESI blocks each page needs two requests.
Object Cache: ON, Redis, host 127.0.0.1, port 6379. On cPanel install Redis with dnf -y install redis && systemctl enable --now redis and the ea-php8x-php-redis extension. This is the biggest single win for admin pages and logged-in users; the page cache does nothing for those.
Browser Cache: ON, 1 year (31557600). Sets Cache-Control on static files; harmless and Lighthouse expects it.

Page optimisation (LiteSpeed Cache → Page Optimization)

Turn these on one at a time and reload the site after each — this is where sites break:

CSS Minify, JS Minify: ON. Safe.
CSS Combine, JS Combine: OFF on HTTP/2 (which is every LiteSpeed server). Combining was a HTTP/1.1 trick; on HTTP/2 it makes every page download one huge file that changes whenever any plugin updates.
Load CSS Asynchronously: OFF, Generate Critical CSS: OFF unless you are chasing a specific Lighthouse score and willing to test every template. The flash of unstyled content it causes annoys real visitors more than it helps a score.
JS Defer / Delay: Deferred is usually fine; Delayed breaks anything that needs JS on first paint (sliders, cookie banners, Elementor animations). If you use Delayed, put jQuery and the theme’s main script in the exclude list.
Lazy Load Images: ON, but exclude the first image on each template (the hero, the featured image) via the Lazy Load Image Excludes list or by adding the skip-lazy class, otherwise Largest Contentful Paint gets worse, not better.
Image Optimization (QUIC.cloud) is optional and needs a domain key; WebP replacement works well. Do not enable Remove original backups until you have seen the results.

Verify

Open an incognito window, load a post twice, and check the headers again: x-litespeed-cache: hit and a TTFB under 100 ms from curl -so /dev/null -w '%{time_starttransfer}\n' https://example.com/. Then log in, edit that post, save, reload in incognito — the change must appear immediately (that is the purge working). Finally, add an item to the cart on a WooCommerce site and confirm the header shows miss or is absent on /cart/; if the cart page shows hit, your exclusions are wrong and customers will see each other’s carts.

When it is still slow

If TTFB is fine but pages feel slow, it is not the cache: run the site through the browser’s Network tab and look for a third-party script or an uncompressed 4 MB hero image. If TTFB on a cache miss is over two seconds, the problem is PHP or the database — start with the mysql-health-snapshot script and Query Monitor, not with more cache options.

LiteSpeed Cache WordPress cPanel at a glance

LiteSpeed Cache WordPress cPanel summary card: LiteSpeed Cache (LSCWP) only does page caching when the web server is LiteSpeed Enterprise or OpenLiteSpeed. — In short: LiteSpeed Cache (LSCWP) only does page caching when the web server is LiteSpeed Enterprise or OpenLiteSpeed.

LiteSpeed Cache WordPress cPanel sections: What has to be true on the server, Cache settings (LiteSpeed Cache → Cache), Page optimisation (LiteSpeed Cache → Page… — Covers: What has to be true on the server, Cache settings (LiteSpeed Cache → Cache), Page optimisation (LiteSpeed Cache → Page Optimization) and Verify.

Official documentation: LiteSpeed documentation, WordPress advanced administration handbook, cPanel & WHM documentation.