Why we picked LiteSpeed over Apache+Varnish for our WordPress customers

Contents

• · What we were optimizing for
• · The things LiteSpeed gets right for WordPress
• · Where Apache+Varnish still wins
• · The memory model and why it matters for shared hosting
• · What we would reconsider

Nobody should pick a web server because a blog post told them to. This post is less "you should use LiteSpeed" and more "here is how we thought about the tradeoff for our specific workload, because the reasoning might be useful for yours".

What we were optimizing for

Our WordPress customers have a specific profile. Most sites have under 10k monthly visitors. A handful have 500k+. Nearly all of them use a mix of a WooCommerce or Elementor-heavy theme, between 15 and 40 plugins, and `.htaccess` rules from years of iteration that nobody remembers the origin of. They want fast pages, they do not want to think about cache invalidation, and they do not want to pay for a tier above shared hosting unless they have to.

That shapes the stack choice. We needed: strong out-of-the-box WordPress caching, `.htaccess` compatibility so we do not rewrite customer rewrite rules, HTTP/3 support, predictable memory under bursty concurrency, and a cache that WordPress itself can invalidate when a post is updated.

The things LiteSpeed gets right for WordPress

LiteSpeed Enterprise runs the same `.htaccess` rules Apache does. That sounds boring until you migrate a site whose `.htaccess` has been hand-tuned for five years and everything keeps working. The rules are parsed natively, not through an Apache compatibility shim.

LSCache is a built-in, server-level cache that the official LiteSpeed Cache plugin can invalidate via a private header (`X-LiteSpeed-Purge`). When an editor updates a post, the plugin tells LSCache exactly which URLs to invalidate, and it happens in microseconds without an out-of-band purge API. You get page caching, object caching (via Memcached/Redis), browser caching, and ESI-like hole-punching for logged-in users, all configured through the WordPress admin.

QUIC/HTTP3 is a first-class citizen. LiteSpeed shipped HTTP/3 support before most of the Apache+Varnish combos had a clean story for it. In practice, HTTP/3 mostly helps mobile visitors on flaky networks: measurable improvement in median time-to-first-byte, smaller but real improvement at the 99th percentile.

The event-driven architecture handles high concurrency without spawning a process per request. For a shared server running 40 WordPress sites, that matters: a traffic spike on one site does not consume the process slots needed by the other 39. We measured a roughly 3-4x reduction in CPU at equivalent request rates versus an Apache+mod_php setup on the same hardware, and memory footprint dropped by about half. Those are our numbers for our workload, not universal truths.

Where Apache+Varnish still wins

This is not a clean win for LiteSpeed across the board, and it would be dishonest to pretend otherwise. Apache+Varnish wins on several real axes.

• · VCL is more powerful than LSCache configuration. If you need programmable cache logic (request normalization, header manipulation, geo-based content variation, stitched ESI responses from multiple backends), Varnish's VCL is a proper language and LSCache's directives are not.
• · No license cost. LiteSpeed Enterprise is commercial software. Apache and Varnish are open source. For an operator running at scale, that matters over time. (OpenLiteSpeed exists and is open source, but lacks some of the Enterprise features we care about, including the full LSCache story.)
• · The Apache ecosystem is larger. More modules, more documentation, more third-party tooling. LiteSpeed's compatibility is excellent, but when something breaks, "the Apache way" usually has more Stack Overflow threads answering it.
• · Varnish is the right answer for non-WordPress workloads with complex caching needs. If we were building a CDN, or caching in front of a custom API, we would reach for Varnish before LSCache.

The memory model and why it matters for shared hosting

This is the part that tipped the decision for our specific use case. Shared hosting lives and dies by density: how many customer sites can you pack onto a single server before latency becomes noticeable?

Apache+mod_php (or Apache+PHP-FPM) has a process-per-request or worker-per-request model. Each PHP worker carries the full WordPress runtime in memory, typically 60-150 MB per worker depending on the plugin stack. For a server with 200 concurrent requests in flight, that is 12-30 GB of PHP worker memory alone, ignoring the HTTP server itself and any reverse proxy.

LiteSpeed's LSAPI handler shares much more memory across concurrent requests and uses a long-lived worker model that keeps opcode caches warm across connections. The same 200 concurrent requests might fit in 6-10 GB. That is the difference between hosting 30 sites per server and 80.

Caveat: this density advantage is specific to PHP workloads. For a Node.js, Go, or Python application, Apache+Varnish and LiteSpeed are closer to equivalent. The memory savings come from LSAPI, which is a PHP-specific protocol.

# Quick sanity check on PHP worker memory for your own stack
# (run on the web server)
ps -o pid,rss,comm -C php-fpm --sort=-rss | head -20

# Total RSS across all PHP workers, in MB
ps -o rss -C php-fpm --no-headers | awk '{s+=$1} END {print s/1024 " MB"}'

What we would reconsider

A year in, two things feel worth revisiting.

First, we would not pick LiteSpeed Enterprise for a workload that is not predominantly WordPress. The density advantage comes from LSAPI, and LSAPI's value is highest when you are running PHP. If we were building out a Node-heavy or Python-heavy platform, OpenResty (nginx+Lua), Caddy, or Apache+Varnish would be in serious contention.

Second, we underestimated how much operational work goes into the LSCache plugin side. The WordPress plugin does a lot (CSS/JS combining, image optimization, database optimization, lazy loading), and most of those features are opt-in for good reason. Customers enable them all at once, something breaks, and the bisect process is painful. We ended up publishing a pared-down recommended configuration and only enabling the aggressive optimizations after a customer opts in.

Stack choice is about fit, not superiority. Pick the one whose tradeoffs match your workload, and be willing to say so out loud.

We still run Apache+Varnish in other parts of the platform. Varnish fronts our status page's API. Apache hosts the customer control panel. For WordPress specifically, LiteSpeed is the right tool. For other things, it is not.