What is LiteSpeed Cache?

LiteSpeed Cache is a high-performance, server-level page cache built directly into LiteSpeed Web Server. This article explains how it works, why it outperforms traditional caching approaches, and how to use it across a wide range of applications.

LiteSpeed Cache (LSCache) is a high-performance, server-level page cache built directly into LiteSpeed Web Server, designed to dramatically speed up dynamic content delivery. Because every Kualo shared hosting server runs LiteSpeed, LSCache is available to every account we host - no additional software, no separate caching layer, and no extra cost.

The official LSCache documentation and plugin downloads are available at lscache.io.

Why server-level page caching matters

Most caching solutions work inside your application - a PHP plugin intercepts the request, generates a cached HTML file, and serves it from disk. This is better than no caching at all, but it still means PHP has to start up, the plugin has to load, and the application has to decide whether to serve the cached copy. Every one of those steps costs time and server resources.

Server-level caching is fundamentally different. When LSCache has a valid cached response for a URL, LiteSpeed Web Server serves it directly - before PHP is invoked at all. No PHP startup, no database connection, no framework bootstrap. The response is returned from memory or disk at near-static-file speed, regardless of how complex the underlying application is.

The practical difference is significant:

A typical WordPress page might take 200-800 ms to generate dynamically. Served from LSCache, the same page can be returned in under 10 ms.
Server resources are freed up for requests that genuinely need dynamic processing - logged-in users, checkout pages, form submissions.
Your site handles traffic spikes far more gracefully, because the server is doing almost no work for the majority of requests.

How LiteSpeed Cache works

LSCache is an output cache for dynamic content. When a cacheable request comes in, LiteSpeed generates the page normally on the first visit, stores the rendered HTML output in the cache, and serves that stored copy to every subsequent visitor until the cache entry expires or is purged.

This is conceptually similar to Varnish, but with one important architectural difference: Varnish is a separate reverse proxy that sits in front of your web server, adding an extra network hop and an additional layer of configuration. LSCache is built directly into LiteSpeed Web Server itself, so there is no separate process, no extra TCP connection, and no VCL configuration language to learn. The cache lives inside the same process that handles the HTTP connection, which makes it both faster and simpler to manage.

Varnish is a powerful tool, but it comes with real complexity. VCL (Varnish Configuration Language) has a steep learning curve, cache invalidation requires careful custom rules, and integrating it with application-level events (such as a product being updated in a CMS) typically requires bespoke development work. LSCache handles all of this through its application plugins, which communicate cache-control and purge instructions directly to the web server using standard HTTP response headers.

The problem with application-only caching

Traditional PHP caching plugins - such as W3 Total Cache or WP Super Cache used in isolation - store cached pages as flat HTML files and serve them via PHP or .htaccess rules. This works reasonably well for simple sites, but it introduces several complications:

Cart and session awareness. A common failure mode is caching a page that contains personalised content - a shopping cart count, a "Welcome back, [name]" message, or customer-specific pricing. Without careful configuration, visitors see each other's data, or the cache has to be disabled for entire sections of the site, undermining its value.
Cache invalidation complexity. When a product is updated, a post is published, or a price changes, the relevant cached pages need to be purged. Application-level plugins vary widely in how reliably they handle this, and misconfiguration can leave visitors seeing stale content for hours.
Plugin conflicts. Caching plugins that rewrite HTML, combine assets, or manipulate headers can conflict with other plugins, themes, or server-level features, leading to broken layouts or JavaScript errors that are difficult to diagnose.

LSCache addresses these problems through a combination of server-level efficiency and application-aware cache control. The application plugin tells the server exactly which pages are public, which are private, and which should not be cached at all - and it handles purging automatically when content changes.

Public cache, private cache, and ESI

Not every page should be cached the same way. LSCache distinguishes between:

Public cache - pages that are identical for all visitors (most blog posts, product pages, category listings). These are cached once and served to everyone.
Private cache - pages that contain user-specific content (a logged-in dashboard, a personalised account page). These are cached per-user in a private cache store.
No cache - pages that must always be generated fresh (checkout, payment processing, form submissions).

For more detail on when each applies, see our article on public cache vs. private cache.

For ecommerce sites, LSCache also supports Edge Side Includes (ESI), which allows a page to be assembled from separately cached fragments. A product page can be fully cached publicly, while the shopping cart widget in the header is served from a private per-user cache fragment. This means even complex ecommerce pages can be served largely from cache, without the risk of showing one customer another's cart contents.

This is the approach used by LiteMage Cache for Magento (described below), and it solves one of the most persistent headaches with ecommerce caching: the cart-breaking problem that plagues simpler caching solutions.

Using LSCache across different applications

LSCache is not limited to WordPress. Because it operates at the web server level and communicates via HTTP headers and .htaccess directives, it can in principle be used with any application that can emit the right cache-control headers or be configured via .htaccess rules.

We provide guides and official plugins for the following:

WordPress - the LiteSpeed Cache for WordPress plugin is the most fully featured integration, covering page caching, image optimisation, CSS/JS minification, database optimisation, and Redis object cache support. See our guide on configuring LiteSpeed Cache with WordPress.
Joomla - install the official LiteSpeed Cache extension. See how to integrate LiteSpeed Cache into Joomla and our Joomla and LiteSpeed Cache reference.
Drupal - the official LSCache module is available for Drupal 8 and above. See how to integrate LiteSpeed Cache into Drupal 8.
PrestaShop - the official LiteSpeed Cache module is available for PrestaShop 1.6 and 1.7. See PrestaShop and LiteSpeed Cache.
Magento - handled via LiteMage Cache (see below).

A full list of official LSCache plugins and integrations is maintained at lscache.io.

Using LSCache with custom applications

If you are running a custom application or a framework that does not have an official LSCache plugin, you can still take advantage of server-level caching by emitting the correct X-LiteSpeed-Cache-Control response headers from your application code, or by adding cache-control rules to your .htaccess file.

For example, a simple .htaccess rule to cache all responses for a static marketing site for one hour might look like this:

<IfModule LiteSpeed>
    CacheLookup on
    RewriteEngine On
    RewriteRule .* - [E=Cache-Control:max-age=3600]
</IfModule>

Developers building custom PHP applications can also emit X-LiteSpeed-Cache-Control headers directly and use X-LiteSpeed-Purge headers to invalidate specific cache entries when content changes. This means it is entirely feasible to build a lightweight cache-purge integration for a bespoke CMS or application framework - you do not need a full plugin to benefit from LSCache.

If you are building a custom integration, the LSCache developer documentation at lscache.io covers the full header specification and purge API.

LiteMage Cache for Magento

LiteMage Cache is a full-page caching solution for Magento stores, built on top of LSCache. It is designed specifically for Magento and uses Edge Side Includes (ESI) hole-punching to assemble both public and private content blocks from cache. This allows even personalised page sections - such as shopping carts or customer-specific pricing - to be served from cache, delivering the fastest possible full-page performance for Magento.

This approach directly addresses the most common failure mode of generic caching solutions on ecommerce sites: a standard page cache will either serve the wrong cart contents to a visitor, or disable caching entirely for logged-in users, leaving most of your traffic uncached. LiteMage caches the page skeleton publicly and assembles the personalised fragments per-user, so you get full-page cache performance without the data-leakage risk.

See our guides on setting up LiteMage in cPanel and integrating LiteMage into Magento 2.

Enabling LSCache on your account

LSCache is available on all Kualo hosting accounts. You need to enable it in cPanel before it will start caching your site. See how to enable LiteSpeed Cache in cPanel.

Once enabled, you can verify it is working by checking the response headers your server returns. See verify if LiteSpeed Cache is working.