Web Servers, Measured
LiteSpeed vs Apache — an event loop against a process pool, measured where it counts
LiteSpeed was built to read Apache's configuration while replacing its architecture. The result is the rare upgrade that changes the numbers without changing your rewrite rules.
The short answer
For a PHP site on shared or cPanel hosting, LiteSpeed is the stronger choice, and the margin grows with concurrency: its event-driven core serves thousands of connections from a handful of processes, while Apache's model ties workers — and their memory — to connections. Under a quiet load the two feel similar; under a busy one they do not.
The practical clincher is compatibility. LiteSpeed reads .htaccess and Apache rewrite rules natively, so the migration that unlocks the event model and the built-in page cache requires no rewriting of the configuration your plugins have spent years accumulating.
By the HostingFast team · Reviewed 25 August 2026
1
Event-driven process serving thousands of connections
.htaccess
Read natively — rules carry over unchanged
HTTP/3
Native in LiteSpeed; module-assembled in Apache
hit
x-litespeed-cache header on a cached page
Apache earned its position honestly: decades of reliability, documentation for everything, and the .htaccess mechanism that let ordinary users configure a server without touching it. Its cost is architectural. Tying worker processes to connections was a sane design when connections were few and short. Modern pages open many, and keep-alive holds them open.
LiteSpeed's bet was that the configuration surface was worth keeping and the architecture was not. It parses Apache's own rule files while serving requests from an event loop, and it puts a page cache inside the server rather than bolting one on. This page measures what that swap is worth.
Process pool against event loop
Apache offers three worker models. Prefork dedicates a whole process to each connection — and with mod_php, each process carries a full PHP interpreter in memory whether the request needs it or not. The worker and event MPMs improve matters with threads, but PHP then moves out to PHP-FPM and the request crosses another boundary.
LiteSpeed's core is an event loop: a small, fixed set of processes multiplexing thousands of sockets, with PHP spoken through LSAPI, a protocol built for the purpose. Memory stays flat as connections climb, which is precisely the condition — a traffic spike, a crawl, a slow-client swarm — under which Apache's per-connection costs turn into swap and queueing.
The .htaccess question, answered properly
The reason .htaccess matters is not sentiment; it is that fifteen years of WordPress plugins, security tools and control panels write Apache rewrite rules automatically. A server that cannot read them turns every rule into a manual translation job.
LiteSpeed reads .htaccess per request, exactly as Apache does, including mod_rewrite syntax and mod_security rules. A cPanel account switched from Apache to LiteSpeed keeps its redirects, its hotlink protection and its plugin-written rules without an edit. That is why the swap can happen platform-wide without customers noticing anything except the numbers.
Where the gap opens: concurrency and the built-in cache
Benchmark a single request against both servers and you will struggle to justify anyone's marketing. The architectural difference prices in as concurrency rises: Apache's cost per connection compounds, LiteSpeed's stays near-flat, and the p95 curves diverge long before either machine looks busy in a dashboard.
The second gap is the cache. LSCache lives inside the server and answers cached requests before PHP is woken; its WordPress plugin manages purging by tag, so a stock change clears exactly the pages it touches. Apache's caching modules exist, but they are assembled rather than integrated, and almost nobody on shared hosting runs them well.
Measuring the two fairly
Same site, same PHP version, same machine class — then step concurrency up with a load tool and watch p95 latency and memory rather than the average. Averages flatter Apache; tails do not.
Verification is a header away: a LiteSpeed-served cached page returns x-litespeed-cache: hit. If you are evaluating hosts rather than servers, run curl against a site each host already serves and read what comes back. Every HostingFast plan fronts PHP with LiteSpeed, so that test is one we invite rather than survive.
Why our platform standardised on LiteSpeed
A shared platform is a concurrency machine: hundreds of sites, one server, spikes that never coordinate. The event model is simply the right architecture for that shape of load, and the native .htaccess support meant adopting it without breaking a single customer rewrite rule.
The cache is the other half. Serving a hit before PHP wakes is the cheapest request a server can answer, and the LSCache plugin gives WordPress precise control over what gets purged and when. Speed you do not have to configure is the kind that survives contact with real users.
- Event-driven serving on every plan, entry tier included
- .htaccess and rewrite rules honoured exactly as Apache would
- LSCache built into the server, managed from a WordPress plugin
- Native HTTP/3, so the transport is modern without extra modules
Why HostingFast
Standard on every plan
Flat memory under spikes
Connections multiplexed by an event loop instead of each claiming a process — the machine stays predictable when traffic is not.
Zero-translation migration
Your accumulated rewrite rules, redirects and security directives work unchanged. The upgrade is architectural, not clerical.
Cache before PHP
LSCache answers repeat visitors from inside the server, tag-purged so it stays correct when content changes.
Quick Start
From order to online
- 1
Check what serves your site today
Read the response headers. A server line and a cache header tell you the architecture and whether anything answers before PHP does.
- 2
Load-test past your comfort zone
Single requests hide the difference. Step concurrency up and record p95 latency and memory on both platforms — the divergence point is the finding.
- 3
Move without rewriting anything
Because LiteSpeed reads Apache configuration natively, migration is a copy, not a port. Ours is free and usually done inside 24 hours.
Built In
Loaded onto every plan
- Event-driven architecture confirmed — not Apache with a cache plugin doing the talking
- .htaccess honoured per request, so plugin-written rules keep working
- Server-level page cache with tag-based purging, not time-based guessing
- PHP spoken over LSAPI rather than proxied through an extra hop
- HTTP/3 served natively and advertised in the alt-svc header
- p95 latency under stepped concurrency measured before you commit
Frequently Asked
What people ask us most often
Is LiteSpeed really compatible with my .htaccess rules?
Yes — reading Apache configuration is a design goal, not an afterthought. mod_rewrite syntax, redirects, access controls and mod_security rules are parsed natively, per request. Sites move from Apache to LiteSpeed on cPanel platforms every day without their rule files being touched.
Will WordPress behave differently under LiteSpeed?
Functionally no — WordPress talks to PHP and MySQL and does not care what serves the request. The differences are additive: the LSCache plugin unlocks server-level caching with tag-based purging, and time to first byte on cached pages drops because PHP is no longer woken to serve them.
Why does Apache slow down under many simultaneous visitors?
Its models attach cost to every open connection — a process in prefork, a thread otherwise — and keep-alive holds connections open between requests. Memory use scales with connections rather than with work, so a spike of slow clients can exhaust the worker pool while the CPU sits mostly idle.
Apache behind an NGINX proxy is common — is that equivalent?
It solves the slow-client problem, since NGINX's event loop absorbs the connections, but requests still land on Apache's worker model, the stack now has two configuration surfaces, and there is still no integrated page cache. It is a sensible patch; LiteSpeed is the same idea taken to its conclusion in one server.
How do I check whether a host actually runs LiteSpeed?
Request any page they serve and read the headers: the server line typically reports LiteSpeed, and a cached page adds x-litespeed-cache: hit. That second header is the one worth caring about — it proves the cache is on and working, not merely installed.
Keep reading
LiteSpeed web hosting
Every plan fronted by LiteSpeed with LSCache enabled — the setup this page measures.
PHP hosting
LSAPI-served PHP with per-site version control from cPanel.
LiteSpeed vs OpenLiteSpeed
Same engine, two builds — what the Enterprise licence actually adds.
Server cache vs plugin cache
Why the cache layer's position in the stack decides its ceiling.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Run your rules on the faster architecture
Your .htaccess works unchanged, your cached pages stop waking PHP, and the migration is free. Measure the before and after inside the 30-day window.
View LiteSpeed web hosting plans