LiteSpeed Hosting
with LSCache on every plan

• Event-driven architecture: one LiteSpeed worker handles thousands of connections, where Apache's prefork model needs a process per connection. Under a traffic spike, the server stays responsive instead of queuing.
• LSCache: a server-level page cache with tag-based purging and ESI (edge side includes), so a cached page can still carry a private block such as a logged-in user's name or a mini-cart. Cached pages are served from the web server without starting PHP, which is why a cached site barely moves the CPU meter.
• LSAPI: LiteSpeed's own PHP interface, faster than PHP-FPM behind Apache for the requests that do reach PHP.
• Drop-in Apache replacement: LiteSpeed Enterprise reads the same .htaccess files and rewrite rules, so every cPanel application works unchanged; on OpenLiteSpeed, .htaccess changes need a restart.
• HTTP/3 and QUIC: LiteSpeed Enterprise supports HTTP/3, which browsers negotiate automatically where it is enabled.

LiteSpeed's own published benchmarks show large gains over Apache for WordPress; we do not publish figures of our own, but the mechanism is simple: a page served from LSCache costs almost no CPU, and on a shared plan CPU is the limit you pay for. The LiteSpeed vs Apache vs Nginx post compares the three in detail.

• WordPress and WooCommerce: the LiteSpeed Cache plugin, installed from the WordPress plugin directory or Softaculous, with page cache, browser cache, database cleanup, image optimisation through LiteSpeed's QUIC.cloud service (optional, with its own account) and ESI blocks for the WooCommerce cart.
• Joomla, Drupal, PrestaShop, OpenCart, Magento 2, Laravel, MediaWiki and XenForo: LiteSpeed publishes an LSCache extension for each, enabled from the application's admin.
• Everything else: any PHP site can be cached with LSCache rules in .htaccess, no plugin needed.

Enable LSCache for WordPress in three steps

1. Install and activate the LiteSpeed Cache plugin from Plugins > Add New (or tick it during a Softaculous install).
2. Open LiteSpeed Cache > Cache and confirm Enable Cache is on; the defaults suit most sites.
3. Load a page twice and check the response headers in your browser's developer tools: x-litespeed-cache: hit means the page came from the cache.

The LiteSpeed Cache setup guide covers the settings that matter for shops and membership sites, and the WordPress caching stack post explains how LSCache, OPcache and browser caching fit together.

Cart, checkout, search and logged-in pages cannot be cached, so a busy shop still needs CPU and RAM for them; that is why the cPanel plans publish cores and memory per tier and why a WooCommerce store should start on Business rather than Starter. A plugin that calls an external API on every request stays slow with any web server. And no cache keeps a site up when the server underneath it fails: every MassiveGRID plan runs on a cluster with 3x replicated storage and automatic failover, so a node failure restarts the account elsewhere instead of taking the cached site down with it. The LVE limits guide explains how to read the CPU and memory graphs in cPanel when a site hits its ceiling.