LiteSpeed vs Nginx vs Apache: Which Is Actually Faster?

A Laravel app moves to a fresh VPS and gets faster. Same code, same database, same traffic, but TTFB drops by half. Nothing was optimised. The old box was simply out of workers. That is usually the honest answer to LiteSpeed vs Nginx vs Apache: the server brand mattered less than whether the process model matched the workload.

Which is not to say the choice is cosmetic. The three servers differ in how they allocate work per connection, what they charge you for per-request configuration, and how they let you throw away a cached page. Get those wrong and no amount of tuning saves you.

Where each server actually sits

W3Techs, checking on 22 October 2026, puts Cloudflare's server at 32.6% of sites whose server is known, nginx at 30.2%, Apache at 21.3%, and LiteSpeed at 13.9% [1]. Those shares count a site once per server it uses, and a large share of busy sites now sit behind a CDN, so read them as a map of the installed base rather than a scoreboard.

The proportions also hide composition. A good part of the nginx figure is nginx running as a reverse proxy or origin in front of another server, and much of the LiteSpeed figure arrives through hosting panels that bundle OpenLiteSpeed. Neither fact tells you which server is faster for your workload.

The concurrency models, briefly

Apache's classic model is a process or thread per connection. MPM Event improved this by moving idle keep-alive connections onto listener threads, so a thousand idle browsers no longer pin a thousand workers [2]. Memory per active request is still real, and it still scales with concurrency.

nginx runs a small number of worker processes, typically one per CPU core, and each handles thousands of connections inside a non-blocking event loop. Sizing comes down to worker_processes and worker_connections, both documented in the core module reference [3]. This is why nginx holds memory flat while Apache climbs.

LiteSpeed is event-driven in the same way and speaks Apache's configuration dialect, including .htaccess. The difference is the PHP path: LSAPI replaces FastCGI, and the cache lives in the server rather than in a plugin.

Per-connection cost

Apache (MPM Event):   [ master ] → thread pool; one thread held per active request
nginx:                [ master ] → N workers (one per core) → epoll event loop
LiteSpeed:            [ event core ] → in-memory cache → LSAPI PHP pool

The .htaccess tax is real and measurable

Apache's own documentation is blunt about this. When AllowOverride permits .htaccess, httpd looks for those files in every directory on the path, and the file is loaded again on every request, so permitting them causes a performance hit whether or not you use them [4].

That is a filesystem lookup and a config parse per request, on every request, forever. On a busy PHP site it is a tax you pay for convenience.

nginx refuses the trade entirely: rewrite rules live in the server block, and nobody edits them through FTP at 11 p.m. LiteSpeed takes Apache's syntax and caches the parsed result in memory, which is how it keeps compatibility without the per-request cost.

The practical takeaway is unglamorous. If you run your own VPS, turn AllowOverride off and put the rules in the vhost. You keep Apache and lose the tax. The compatibility argument only matters when strangers edit config, which is exactly the shared-hosting case.

Cache invalidation decides more than raw speed

Serving a cached page is fast on all three. The differences show up when a page changes.

LiteSpeed's LSCache is tag-based: entries carry tags, and purging a product purges the pages tagged with that product, leaving the rest of the cache warm [5]. For a WooCommerce store with 4,000 SKUs, that is the difference between a warm cache and a cache that empties every time someone edits a price.

nginx's FastCGI cache is file-based. Purging means clearing files or keys, usually through a third-party module or a small service you write and maintain. It works well when your content changes on a schedule, and it becomes a project when inventory changes every few minutes.

Apache's mod_cache sits somewhere in between and is rarely the reason anyone picks Apache.

What the vendor benchmarks actually measure

LiteSpeed publishes its own comparison benchmarks against Apache and nginx [6]. They are worth reading, and they are vendor-run. The request rates assume a cache hit, a specific PHP version, and hardware you probably do not own. A 3x headline usually describes a cached WordPress page, not an authenticated checkout.

That does not make the numbers dishonest. It makes them narrow. If your workload is cached WordPress, expect a real gap. If your workload is an API with a 40 ms database call behind every request, the web server is a rounding error and the gap shrinks to nothing.

Test your own stack instead. It takes an afternoon:

• Pick two URLs: one cacheable page, one that hits PHP and the database.

• Run wrk or hey against each for 60 seconds at concurrency 50.

• Record p50, p95, and p99 latency, plus peak RSS for the server process.

• Repeat after switching servers, changing nothing else.

The p95 number is the one your users feel. Average request time is a vanity metric that hides every queue.

The comparison that matters

Choosing by workload

For WordPress and WooCommerce, LiteSpeed or OpenLiteSpeed with LSCache is the least work per unit of speed, provided you accept the licence cost for the Enterprise build. OpenLiteSpeed is free and shares the core, but .htaccess changes need a graceful restart rather than applying live.

For an API gateway, a Node.js or Go backend, or a static asset tier, nginx is the default for good reasons: predictable memory, a config file you can review in a pull request, and a wide module set. If you are deploying Node behind it, our Node.js deployment walkthrough covers the proxy and process-manager side.

For legacy panel hosting where dozens of users need their own rewrite rules, Apache with MPM Event and PHP-FPM is not a compromise. It is the requirement.

The honest trade-off: LiteSpeed Enterprise costs money per worker tier, nginx config is code your team has to own, and Apache will always be the slowest of the three on dynamic PHP at high concurrency. None of those is disqualifying. They are just different bills.

Sizing the server before you pick one

A web server cannot use cores you did not buy. If the app is PHP-heavy, the CPU profile that matters is per-request execution, and vertical scaling beats horizontal tinkering. If it is a Laravel app using Octane, the long-lived workers change the maths entirely, which is why Octane hosting requirements are worth checking before you tune anything.

On a VPS you control, start with worker_processes auto; and worker_connections 2048;, then watch memory under load rather than guessing. Pair that with NVMe storage, because a warm cache still has to be built from disk on the first request after a deploy.

Then measure the thing you actually sell. If page speed is your pitch, the connection between speed and search performance is worth understanding before you swap servers for a number on a chart.

Any of the three runs well on an NVMe-backed cloud hosting plan with dedicated CPU, which is the part of LiteSpeed vs Nginx vs Apache that nobody argues about. The server software decides your ceiling. The hardware decides whether you reach it.