LiteSpeed on a network of many small sites

The web server matters most at the moment many sites on one machine are asked for something at once. LiteSpeed handles that moment with an event driven design and a built in cache, which is why it is the default across our shared and WordPress platforms rather than an option you configure.

The difference in one sentence

A traditional Apache setup dedicates a worker to each connection and holds it until the response is finished. An event driven server handles many connections in one process and only does work when a connection actually has something to say. Under a handful of visitors nobody can tell the difference. Under a hundred slow mobile connections across thirty sites, the first design runs out of workers and the second does not.

Why this shape suits a multi-site network

A network of content sites has an unusual traffic profile. Rather than one site with heavy sustained load, you have dozens of sites each receiving a trickle, plus crawlers arriving on their own schedule and hitting several of your sites in the same minute. The total request rate is modest but the concurrency is spread thin and unpredictable.

That is the profile where per connection workers waste the most, because most of those connections are idle most of the time, waiting on a slow network rather than on your server. Handling them without dedicating a worker to each is the whole advantage.

The part that matters more than the architecture

Honestly: for a content site, the cache does more than the server model. A page served from cache never reaches the application at all, so PHP does not run, the database is not queried, and the response is assembled from a stored copy. That is a change of an order of magnitude, and it dwarfs the difference between web servers on the same workload.

The practical reason LiteSpeed is worth having is that the cache is part of the server rather than a plugin bolted on top. Caching decisions happen before the request reaches PHP, which is exactly where you want them. This is covered in the rest of this section.

What it is compatible with

The configuration you already know keeps working. Rewrite rules in .htaccess are read, the same directory structure applies, and the control panel behaves as expected. Migrations from an Apache host do not require rewriting your rules, which removes the usual reason people avoid changing web server.

What it does not do

Being precise here saves disappointment:

• It is not a ranking factor. No search engine rewards a particular web server. What is measurable is response time, and that is worth having on its own terms.
• It does not fix a slow query. An uncacheable page backed by a bad database query is slow on any server.
• It does not create address diversity. How your sites relate to one another from outside is decided by the addresses they answer on, not the software serving them. That is a separate product decision.
• It does not replace a CDN for distance. Physics still applies to a request crossing an ocean, which is why the European pool exists for European audiences.

What to check on your own sites

Rather than taking the architecture on faith, confirm the outcome. Load a page twice and compare the time to first byte. A cached response should be dramatically faster than the first, uncached one. If both are equally slow, caching is not doing its job and the web server is not the reason.

The product documentation is at docs.litespeedtech.com. For the resource limits your account runs inside regardless of web server, see Platform and Limits.