How LiteSpeed Cache works
When a visitor requests a page, the web server normally hands the request to PHP, which loads WordPress, runs its plugins, queries the database and assembles the HTML. LSCache sits in front of that. The first time a page is requested it lets PHP build it, then stores the finished HTML in the server's cache with the page's URL as the key. Every request after that, from anyone, gets the stored copy straight from the web server in a fraction of the time. The cache is at server level, in LiteSpeed itself, not in PHP, which is why it's faster than a caching plugin that stores files WordPress still has to serve.
Each cached page has a TTL, after which it's rebuilt, and the platform plugin purges it early when the content changes: publish a post, and the post, the home page and the category pages are purged. The response headers tell you what happened: X-LiteSpeed-Cache: hit means the copy came from the cache, miss means PHP built it this time.
The plugins: WordPress, Magento, Joomla and the rest
LSCache is the server module; each platform has a plugin that speaks to it. LiteSpeed Cache for WordPress is the best known and also bundles image optimisation, CSS and JavaScript minification, an object cache connector for Redis or Memcached, and a CDN option through QUIC.cloud. There are official plugins for Magento, Joomla, Drupal, PrestaShop, OpenCart, Laravel and others, and a generic rewrite-rule approach for anything else.
ESI and private cache: caching pages that aren't the same for everyone
A page with a "Hello, Sarah" in the header or a basket count can't be served identically to everyone. LSCache handles that with ESI (Edge Side Includes): the page is cached publicly, and the small personal fragment is marked as a separate block that's either fetched fresh or served from a private cache keyed to that visitor. On WordPress the plugin does this for the admin bar, comment forms and WooCommerce widgets. It's the difference between caching 20 percent of a shop and caching 95 percent of it.
LSCache is LiteSpeed's caching system. It can keep a ready-made response so eligible requests do not need the application to rebuild the page every time. That can reduce server work, but it does not make every part of a website equally fast.
Server caching and the WordPress plugin
LiteSpeed Cache for WordPress connects WordPress to the caching service and provides optimisation controls. Installing a plugin alone is not proof that server-side page caching is active. The server or supported service must provide it, and the page must be eligible for caching. See the LiteSpeed plugin documentation for its cache and optimisation features.
Check a cache hit before changing settings
Choose a public page, open it while logged out and inspect the response headers in browser developer tools. Repeat the request and look for the cache headers relevant to your server or CDN. A MISS followed by a HIT can show a newly cached response; an exclusion, cookie or cache-control rule may keep a page uncached.
Record the page, test location and cache state when comparing timings. A single cached homepage result should not stand in for an entire store's performance. Our UK WordPress hosting uses LiteSpeed with LSCache, and the platform page explains the underlying stack.
Protect personalised pages
A basket, checkout or account page may contain visitor-specific data. Use the appropriate application integration and verify its exclusions. Test with separate browser sessions so you can check that one shopper's data never appears to another. Avoid enabling several overlapping page-cache plugins at once.
Tune one change at a time
Keep a staging copy and a backup. Change one optimisation setting, clear the relevant cache and test the page's images, menus, forms and checkout. Combining or delaying scripts can affect behaviour even when a speed score improves. Measure loading and interaction as well as server response time.
When content looks stale, check each cache layer, including the browser and CDN. If you need help, send the affected URL, whether you were logged in and the response headers. Those details are more useful than a screenshot of a single performance score.
LSCache FAQs
How do I clear the LiteSpeed cache?
In WordPress, use the LiteSpeed Cache item in the admin toolbar and choose Purge All, or go to LiteSpeed Cache, Toolbox, Purge. Purging one page is under the same menu when you're viewing it. On other platforms the plugin has an equivalent purge button. Our support team can purge server-side if a page is stuck.
Should I delete the cache?
Purge it when content looks stale after a change, after switching theme or plugins, or when a developer asks you to. Don't purge on a schedule "to be safe"; every purge means the next visitor to each page waits for PHP to rebuild it.
When should you not cache a page?
Anything that differs per visitor or must be current to the second: the checkout, the basket, account pages, a logged-in dashboard, and pages behind a login. The WordPress plugin excludes these by default and ESI handles the small personal bits on otherwise public pages. Test with two browsers, one logged in and one not, before trusting any change.
Does LSCache work on shared hosting?
Yes, that's where it's most used. It needs LiteSpeed Enterprise on the server, which our cloud hosting and WordPress hosting plans run, plus the platform plugin on the site.
Hosting that keeps up
UK NVMe hosting on AMD EPYC and LiteSpeed.
NVMe SSD storage on every plan, LiteSpeed caching and free managed migration, run by a UK team.