LSCache (LiteSpeed Cache) Guide: Server-Level Caching for WordPress

LSCache is not a separate application or plugin — it is a page cache engine baked into LiteSpeed Web Server (LSWS) and its open-source sibling OpenLiteSpeed. The LiteSpeed Cache plugin for WordPress sits at over 5 million active installations and replaces an entire FastCGI + Varnish + Redis trio with almost no configuration. Because the cache lives at the web server level, the PHP process is never invoked on a hit; the request is served straight from LSWS''s C++ code path.

This article unpacks what makes LSCache different from FastCGI cache, Varnish or WP Rocket, walks through the .htaccess and plugin configuration, integrates QUIC.cloud CDN, sets up ESI for fragment caching, and looks at real Core Web Vitals improvements seen on production servers. Audience: WordPress site owners, hosting admins and performance-focused engineers. Every command was tested on LSWS Enterprise 6.x and OpenLiteSpeed 1.7+.

Related guides: What is DNS, settings · Domain names & WHOIS lookup · Hosting types guide · Nginx configuration · Plesk panel guide

What LSCache Actually Is

LSCache is a cache engine that runs inside the LiteSpeed Web Server process itself. Unlike Apache + Varnish + Redis, there is no extra port, no extra socket, no separate daemon. When a request lands, LSWS first checks its cache store under /usr/local/lsws/cachedata; on a hit it answers without ever touching PHP-FPM. On a miss it forwards to the backend, writes the response, and serves all subsequent requests directly from cache. The cache key by default is scheme + host + URI + vary.

The practical consequence: configuration is roughly half of an Nginx + FastCGI cache stack, the connection ceiling is roughly twice as high, and on static content LiteSpeed benchmarks show up to 9x the throughput of stock Apache. CPU usage is typically 30-50% lower because there is no mod_php memory pressure; each LSWS worker runs an asynchronous event loop that multiplexes many connections.

The cache store is disk-backed, but the plugin can also attach to Redis or Memcached for object cache. Disk cache performance on NVMe servers is close to RAM cache, and the cache survives a server restart — which neutralizes one of Varnish''s biggest weaknesses (its default in-memory storage).

LSWS, OpenLiteSpeed and Licensing

There are two distributions: LiteSpeed Web Server Enterprise is commercial and licensed per-server (commonly bundled in cPanel/Plesk hosts); OpenLiteSpeed is fully open source and free. Both ship with the LSCache module, but the Enterprise build has more mature .htaccess parity and panel integrations. OLS pairs perfectly with CyberPanel for a free production-ready VPS stack.

• LSWS Enterprise: byte-for-byte Apache .htaccess compatible, cPanel/Plesk plugin available, paid license
• OpenLiteSpeed: open source, GPL, no cPanel support, ships with CyberPanel
• LSCache module: included in both editions, no extra license
• QUIC.cloud: separate CDN service, free quota, optional premium plans

How It Differs From FastCGI Cache, Varnish and WP Rocket

Nginx FastCGI cache is also strong, but it requires an explicit cache zone in /etc/nginx/conf.d, manual fastcgi_cache_bypass rules and custom purge hooks. To clear cache on WordPress post updates you also need a separate Nginx Helper plugin. Varnish is a third process and cannot terminate TLS — it sandwiches between Apache or Nginx, VCL rules are a separate language and debugging requires specialist skills. Redis object cache only stores object-level results (database queries), not the full page; PHP still re-renders the page every request.

WP Rocket is a disk cache that runs from inside PHP — every request must at least partially bootstrap WordPress, because the advanced-cache.php drop-in lives inside PHP. Even on a hit there is non-zero PHP time; typically a 30-80 ms bootstrap latency. LSCache combines all three: page cache + object cache + optional browser cache + image optimization, all from a single plugin. The crucial difference: on a cache hit, PHP never runs. Even WP Rocket must touch PHP, while LSCache answers straight from LSWS''s C++ code path with TTFB typically falling to 8-15 ms.

Another axis is configuration complexity. Setting up Nginx FastCGI cache correctly for WordPress takes around 80-120 lines of nginx.conf, plus the Nginx Helper plugin, plus manual fastcgi_cache_bypass logic. Our Nginx configuration guide has a worked example. With LSCache you reach the same outcome via the plugin''s Cache: ON toggle and a 4-5 line .htaccess block.

Installing the WordPress Plugin

Install and activate LiteSpeed Cache. The server does NOT have to be LSWS or OpenLiteSpeed for the plugin to be useful — CDN-based page cache via QUIC.cloud still works. But the real value lands when the host runs the LSCache module. You can verify the host recognizes the cache module by checking for the X-LiteSpeed-Cache-Control response header; if that header is missing, the LiteSpeed binary was compiled without the cache module — and on OLS the cachedata directory must exist.

// wp-config.php — required so the plugin can compute its cache keys
define('WP_CACHE', true);

// On multisite, network-activate object cache:
define('LSCWP_OBJECT_CACHE', true);

// Disable the plugin entirely in dev:
// define('LITESPEED_DISABLE_ALL', true);

Once active, you get a WP Admin > LiteSpeed Cache > Cache menu. Key toggles: Enable Cache: ON, Cache Logged-in Users: OFF (default; flip to ON with ESI), Cache Commenters: OFF, Cache REST API: ON, Cache Mobile: ON. The default Public TTL of 604800 seconds (1 week) is fine; for personalized pages a Private Cache TTL of 1800 seconds works well.

LSCache Rules in .htaccess

LSWS Enterprise parses Apache .htaccess byte-for-byte; the plugin writes the block below into .htaccess on activation. On OpenLiteSpeed you have to translate the same rules into the vhost.conf rewrite directive.

# BEGIN LSCACHE
<IfModule LiteSpeed>
CacheLookup on
RewriteEngine On
RewriteRule .* - [E=Cache-Control:max-age=120]

# Do not cache login or cart pages
RewriteCond %{REQUEST_URI} (/wp-admin/|/wp-login\.php|/cart/|/checkout/|/my-account/) [NC]
RewriteRule .* - [E=Cache-Control:no-cache]

# Use private cache when wp-postpass cookie is set
RewriteCond %{HTTP_COOKIE} wp-postpass_ [NC]
RewriteRule .* - [E=Cache-Control:vary=wp-postpass]
</IfModule>
# END LSCACHE

QUIC.cloud CDN Integration

QUIC.cloud is the official CDN built by LiteSpeed Technologies and is the natural extension of LSCache. The anycast network has 80+ POPs, supports HTTP/3 (QUIC), and bundles image optimization, critical CSS generation, low-quality image placeholders (LQIP) and DNS hosting. The free tier ships 10 GB of monthly CDN traffic and 500 image-optimization quotas; for higher traffic there are Standard ($0.03/GB) and Premium tiers. Unlike Cloudflare, the CDN edge talks directly to LSCache — page cache invalidation is automatic, no manual API call required.

Register your domain through General > QUIC.cloud Domain Key, then run Image Optimization > Pull Images to convert the entire media library to WebP in a single click. Critical CSS is also generated on QUIC.cloud servers — you do not have to install Puppeteer or Chromium yourself. The DNS service adds DNSSEC support on top of anycast nameservers. With Object Storage you can ship WebP variants from the edge instead of your origin — origin traffic typically drops 60-70%.

# Purge QUIC.cloud CDN cache (wp-cli)
wp litespeed-purge cdn

# Purge a single URL
wp litespeed-purge url https://example.com/blog/post-slug/

# Purge everything (server + CDN)
wp litespeed-purge all

ESI: Cached Pages with Logged-in User Menus

The classic problem with full-page cache: when a user logs in, the personalized menu ("Welcome Egemen, Cart (3)") is wrong, so cache is disabled for them. ESI (Edge Side Includes) solves this — the bulk of the page is cached publicly, and only personalized fragments are rendered on every request. ESI is a 2001 W3C submission from Akamai and Oracle; LSCache implements a native subset of ESI 1.0. Varnish also has ESI but has to be wired up manually through VCL; the LSCache plugin auto-detects most ESI fragments.

<!-- Inside a theme file or widget render function -->
<esi:include src="/?lscwp_esi=user-menu" cache-control="private,max-age=1800" />

<!-- LSCache keeps a separate TTL and vary key for this fragment -->

Inside the plugin, set ESI Settings > Enable ESI: ON. The plugin moves the Admin Bar, the Comment Form and the Login Status to ESI automatically. For WooCommerce mini-cart or Easy Digital Downloads dashboards, add the corresponding nonces under ESI Nonces.

Cache TTL, Public/Private and Vary

LSCache uses three flavors of cache key: public (same for everyone), private (per cookie/IP), vary (split on a condition). For WooCommerce, an empty-vs-full cart is a vary key; for WPML, the active language is a vary key. From Cache > Object the plugin can attach to a Memcached or Redis backend; combining object cache with page cache pushes database query counts down by up to 95%. Redis is the preferred object cache backend because it has a persistent storage option; Memcached is RAM-only and loses everything on restart.

When choosing TTLs, avoid both extremes: very short TTLs hurt hit rate and increase PHP load; very long TTLs raise the risk of serving stale content. One week + auto-purge is the best balance for WordPress. The CDN layer applies an additional TTL; QUIC.cloud edge cache TTL is independent of origin TTL and is usually read from the max-age header.

• Public TTL: 604800 seconds (1 week) — anonymous visitors
• Private TTL: 1800 seconds (30 minutes) — logged-in users
• Front Page TTL: 604800 — homepage
• Feed TTL: 604800 — RSS feeds
• 404 TTL: 3600 — 404 pages (kills DDoS amplification)

Auto Purge and WP Hook Integration

The plugin automatically purges affected cache keys on post update/delete, comment creation, theme switch, plugin update and more. The purge isn''t limited to that single post — it also covers the homepage, category archive, tag archive, author archive, date archive, RSS feed and sitemap. From your own code, call do_action(''litespeed_purge_post'', $post_id) to drop a post''s cache, do_action(''litespeed_purge_url'', $url) for a specific URL, or do_action(''litespeed_purge_all'') to wipe everything.

Beyond WordPress events, what else triggers a purge? litespeed_purge_private_all clears all private cache, litespeed_purge_esi drops ESI fragments, litespeed_purge_object wipes the object cache. WooCommerce hooks stock changes, cart emptying and coupon updates into custom filters. Tag-based purge is critical for dynamic content: tag a post via litespeed_purge_tag and you can later purge that tag in bulk.

// Custom plugin: when WooCommerce stock changes, purge the product page and category list
add_action('woocommerce_product_set_stock', function($product) {
    $product_id = $product->get_id();
    do_action('litespeed_purge_post', $product_id);

    // Also purge category archives
    $terms = get_the_terms($product_id, 'product_cat');
    if ($terms) {
        foreach ($terms as $term) {
            do_action('litespeed_purge_url', get_term_link($term));
        }
    }
});

Cache Exclusions: Cookies and URI Patterns

Cache > Excludes lets you list URIs that must never be cached (e.g. /checkout), query string parameters (add-to-cart), cookies (wp-postpass, wordpress_logged_in), user agents (Googlebot for debugging) and roles (administrator). A cookie value can also be used as a private cache key. WordPress nonces rotate every hour, so be careful with personalized post-login pages: if a nonce is not flagged as an ESI fragment, the on-screen forms silently fail 24 hours later.

For WooCommerce installs, the woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_* cookies trigger automatic bypass. For EDD (Easy Digital Downloads) you have to add edd_items_in_cart and edd_session manually. UTM parameters (Google Analytics, Facebook click IDs) are deliberately excluded from the cache key by default; that''s correct, otherwise every UTM combination would mint its own cache version.

# Verify cache hit — curl with the X-LiteSpeed-Cache header
curl -sI https://example.com/blog/sample-post/ | grep -i 'x-litespeed\|cache-control'

# Expected output:
# x-litespeed-cache: hit
# cache-control: public, max-age=604800

# On miss:
# x-litespeed-cache: miss

Image Optimization, CSS/JS Minify and Critical CSS

The Page Optimization tab inside the LSCache plugin removes the need for Autoptimize or WP Rocket. Image Optimization batches the entire media library through QUIC.cloud and converts to WebP (originals are kept; fallback works automatically). CSS/JS minify + combine + defer + async are toggle-driven. The Critical CSS generator produces above-the-fold rules per page type and on Core Web Vitals tests can drop LCP by 1-2 seconds. UCSS (Unique CSS) goes one step further: it strips CSS the page never uses; file size typically falls 70-80%.

Be careful with CSS/JS combine: legacy plugins that depend on jQuery can break when load order changes after combine. Add problem scripts to JS Excludes to keep them out of combine. Defer JS is a safer default than async; Inline JS collects small inline scripts and loads them asynchronously. On the font side Font Display Optimization auto-applies font-display: swap to every @font-face rule — FOIT (flash of invisible text) disappears completely.

• WebP/AVIF conversion: media library wide, bulk job
• Lazy load: native loading="lazy" + LQIP placeholder
• CSS Combine: collapse all stylesheets into one
• JS Defer: postpone render-blocking scripts
• Critical CSS: inline above-the-fold CSS, async the rest
• Font Display: applies font-display: swap automatically

Control Panel Integrations

cPanel and WHM: the LiteSpeed Cache Manager module gives per-account queue control on shared hosting. Plesk: the LiteSpeed Server extension manages cache per subscription. DirectAdmin: install LSWS via custombuild, edit vhost.conf through the panel''s file editor. CyberPanel: an open-source panel built on OpenLiteSpeed that delivers a production-ready stack with zero license cost. See our Plesk panel guide for panel-specific details.

Which panel to choose? If you''re building reseller hosting with multiple customers and already license cPanel, LSWS Enterprise + cPanel is the natural pick. If you''re running a single-VPS WordPress or Laravel project, CyberPanel + OpenLiteSpeed brings the license cost to zero — you only pay for RAM and CPU. Plesk delivers the most polished GUI but the LiteSpeed extension is an extra license. For cloud-native deployments you can run the official litespeedtech/openlitespeed Docker image and skip the panel entirely.

CLI: lsws Control and Cache Purging

# Reload LiteSpeed Web Server (after a config change)
/usr/local/lsws/bin/lswsctrl reload

# Full restart
/usr/local/lsws/bin/lswsctrl restart

# Version and status
/usr/local/lsws/bin/lswsctrl version
/usr/local/lsws/bin/lswsctrl status

# Wipe the on-disk cache (manual purge)
rm -rf /usr/local/lsws/cachedata/*
/usr/local/lsws/bin/lswsctrl reload

# Purge only the WordPress cache via wp-cli
wp litespeed-purge all
wp litespeed-purge tag post_123
wp litespeed-purge post_id 123

Benchmark: WP Rocket vs LSCache vs FastCGI Cache

On the same VPS (4 vCPU, 8 GB RAM, NVMe) with WordPress 6.4 and the Astra theme, k6 tests typically show: WP Rocket disk cache 700-900 RPS; Nginx FastCGI cache 4500-5500 RPS; LSCache 6000-8000 RPS. With QUIC.cloud and Critical CSS turned on, LSCache lands LCP at 1.2-1.4 s, FastCGI cache at 1.6-2.0 s. On INP, LSCache''s JS Defer pipeline easily stays below 100 ms. Methodology: 60-second ramp-up, 30-second steady load, 100 concurrent virtual users, single home-page request — in real-world traffic, cookie-bound pages (dashboard, cart) drop well below those numbers.

Don''t over-read the numbers — those gaps were measured on a low-TTFB VPS. On shared hosting, I/O latency dominates over the cache engine choice. If the server disk is HDD, no cache engine helps; cache I/O is included and disk seek time dominates. Measure both peak throughput and p99 latency separately; a great average RPS with a 3-second p99 still produces a poor user experience. For a broader Core Web Vitals breakdown see our Core Web Vitals 2026 guide. Don''t ignore RUM (Real User Monitoring) data either: synthetic tests cannot reproduce real-world connection quality.

Migrating from WP Rocket or W3 Total Cache

First rule: COMPLETELY DEACTIVATE the old plugin and remove its files. Delete wp-content/cache. Delete the wp-content/advanced-cache.php and object-cache.php drop-ins. Leave the existing WP_CACHE definition in wp-config.php. Then install LSCache; the plugin writes the new drop-ins on first run. Watch out during migration: WP Rocket has its own image lazy-load implementation, so any custom CSS that depends on it may need its data-src attributes re-tagged for LSCache''s lazy-load.

When migrating from W3 Total Cache, note: W3TC supports distributed cache via Memcached clusters. LSCache object cache binds to a single Memcached/Redis instance; for multi-node clustering use Redis Sentinel or Cluster mode. W3TC''s minify module is notoriously broken and often breaks the site; LSCache combine + minify is generally smoother but still validate it on staging.

# Migrating off WP Rocket — clean slate
cd /var/www/html
wp plugin deactivate wp-rocket
wp plugin uninstall wp-rocket
rm -rf wp-content/cache
rm -f wp-content/advanced-cache.php
rm -f wp-content/object-cache.php
rm -rf wp-content/plugins/wp-rocket

# Install and activate LSCache
wp plugin install litespeed-cache --activate
wp litespeed-option set cache true
wp litespeed-purge all

LSCache for Magento, OpenCart and Drupal

Beyond WordPress, the litespeedtech team ships free extensions for Magento 2, OpenCart 3.x/4.x, PrestaShop, Drupal 9/10, Joomla 4.x, XenForo and MediaWiki. The mechanics are identical: ESI fragments, public/private cache, vary cookies. For Magento the primary vary key is customer_logged_in; for OpenCart it is currency and language.

In Magento 2, the LSCache extension replaces the native full_page_cache backend; flip the page_cache driver under cache_types in app/etc/env.php to LSCache. Drupal''s module is installed via composer require litespeedtech/lscache-drupal, then enable the cache.backend.lscache service. Joomla''s extension is a System plugin that hands page caching off from Joomla''s own disk cache to LSWS. OpenCart ships through the marketplace as a free extension installed from the control panel.

Troubleshooting: Cache Isn''t Working

The five most common causes: (1) X-LiteSpeed-Cache: no-cache is returned — a cookie or plugin is disabling cache; check the Crawler > Disable report. (2) Cache always misses — query string params (?utm_source=...) shard the cache key; add them to Drop Query Strings. (3) Logged-in users see no cache — Private Cache is off or ESI is disabled. (4) WooCommerce pages don''t cache — the woocommerce_cart_hash cookie triggers a bypass; that''s normal behavior. (5) X-LiteSpeed-Cache header is missing entirely — the host is not running LSWS, the plugin is only acting through QUIC.cloud.

For deeper debugging, watch the LSWS error log: tail -f /usr/local/lsws/logs/error.log. Enabling Cache > Debug Log writes every cache decision to wp-content/debug.log; DON''T FORGET TO TURN IT OFF in production — the log file can hit several GB per hour. Also drop the WordPress heartbeat interval (to 60 s) under Toolbox > Heartbeat to reduce unnecessary admin-page cache invalidations.

Security: Cache Poisoning and Header Injection

The classic weakness of any cache engine: an attacker forges a request with a misleading X-Forwarded-Host header to write a poisoned URL into cache. By default LSCache only includes the request URI and Host header in the cache key; be careful when adding extra headers to the vary list. A custom fastcgi_cache_key-style rule can be written manually into vhost.conf. The Cache Vary chapter of the LSCache documentation is required reading.

A second security concern: private cache leak. If login state is bound to a session rather than a cookie, and the session ID is exposed in the URL (legacy PHP behavior), several users can end up writing into the same private cache key. Modern WordPress is not affected, but for custom membership plugin flows, use the litespeed_vary_cookies filter to add session_id() to the cache key. Also remember to keep HTTP Strict Transport Security and Content Security Policy headers on the response — the plugin does not add them automatically.

References

• LSCache official documentation
• LSCache WordPress plugin docs
• LiteSpeed Cache for WordPress
• litespeed-cache GitHub repo
• QUIC.cloud CDN
• OpenLiteSpeed
• LiteSpeed Benchmarks
• ESI 1.0 W3C specification
• web.dev Core Web Vitals
• CyberPanel — OpenLiteSpeed control panel
• LiteSpeed Technologies

Modern Web Hosting and Server Infrastructure

A performant web hosting service rests on three infrastructure decisions: NVMe SSD disks (4-6× IOPS over SATA SSD), LiteSpeed Web Server or Nginx + LSCache (9× request capacity over Apache) and CloudLinux + Imunify360 isolation. The hosting provider's control panel (cPanel, Plesk, DirectAdmin), daily backup policy, data center location and support response time make a big difference too. Turkish locations give low latency to local visitors, while Hetzner Frankfurt or OVH Roubaix suit global traffic. As your site grows, transitioning from shared hosting to VPS to dedicated server scales CPU/RAM/disk to your needs.

Related Articles

• Page Speed and Core Web Vitals 2026
• Nginx Configuration: Reverse Proxy, Cache and Rate Limiting
• Plesk Panel Management: Domains, Databases, Email and SSL