Every WordPress host runs on top of a web server, and the choice between LiteSpeed, Nginx, and Apache gets debated constantly. Most of that debate focuses on raw speed, but the more useful question is how each server handles the two things that actually determine your site’s real-world performance: .htaccess compatibility and cache integration. Get those right and the underlying server matters far less than people assume.
How the three servers actually work
Apache uses a process or thread per connection model. Each incoming request gets its own worker, and Apache reads configuration on a per-directory basis through .htaccess files. This is flexible and forgiving, which is why Apache became the default on so much shared hosting, but it also means more overhead per request under heavy concurrent load.
Nginx took a different approach: a single event-driven process handles many connections asynchronously instead of spinning up a worker per request. That makes it lighter under concurrency, but Nginx has no concept of .htaccess. All rewrite rules, redirects, and security directives have to live in the main server configuration, which typically only your hosting provider can edit.
LiteSpeed sits in between architecturally. It uses the same event-driven model as Nginx for efficiency, but it was built to be a drop-in replacement for Apache, which means it reads and honors .htaccess files natively. You get Nginx-like request handling with Apache-like configuration compatibility.
The .htaccess factor
This matters more for WordPress than most other software because WordPress leans on .htaccess constantly. Permalink structures, security hardening rules, plugin-added rewrites, and directory protection all typically get written into that file. WordPress plugins that add rewrite rules almost universally assume Apache-style directives.
On Apache, this just works. Install a plugin that needs a rewrite rule, and it writes to .htaccess, and the change takes effect on the next request with no server restart needed.
On Nginx, none of that happens automatically. Rewrite rules have to be translated into Nginx syntax and placed in the server block, which usually means a support ticket or a manual edit by someone with server access. This is one of the most common sources of frustration when migrating a WordPress site onto an Nginx-only stack: permalinks break, a plugin’s rewrite stops working, and there is no local file to fix.
LiteSpeed avoids this entirely by reading .htaccess the same way Apache does. That is a meaningful practical advantage for WordPress specifically, since it means the migration risk that comes with Nginx largely disappears while still getting an event-driven server underneath.
Cache integration is the real decider
Once the architecture questions are settled, the thing that actually moves Core Web Vitals numbers (LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1) is how well caching is wired into the stack, not which server is technically fastest at serving a static file.
There are two layers worth separating:
- Full-page cache: stores a fully rendered HTML version of a page so PHP and the database never get touched for that request.
- Persistent object cache: stores the results of expensive database queries in memory (via Redis or Memcached through a drop-in) so logged-in users, WooCommerce carts, and dynamic content still avoid repeated database hits even when full-page caching cannot apply.
Apache setups typically rely on a caching plugin that writes static HTML files to disk, or on a separate reverse proxy like Varnish sitting in front of the server. Both work, but they add moving parts and configuration surface.
Nginx is commonly paired with FastCGI cache, which is fast but usually requires manual server-block configuration rather than anything a plugin can manage on its own. That is fine if your host has already tuned it, but it is not something a site owner can adjust from the WordPress dashboard.
LiteSpeed’s advantage here is that its caching integrates directly with the server through the LiteSpeed Cache plugin, which talks to the server’s built-in page cache over its own API rather than shelling out to an external proxy or relying purely on static file generation. Purging, cache exclusions, and per-page rules are managed from inside WordPress, which removes a layer of coordination between the application and the server.
Regardless of which server sits underneath, Redis or Memcached object caching works the same way: a drop-in file connects WordPress to the memory store, independent of whether the web server is Apache, Nginx, or LiteSpeed. This layer is worth confirming is active on any host, since it is what keeps dynamic pages fast even when full-page caching cannot serve a logged-in request.
PHP processing matters too
The web server hands PHP requests off to a PHP process one way or another. Apache and Nginx typically use PHP-FPM. LiteSpeed uses its own LSAPI, which is functionally similar but tends to have lower overhead per request. In either case, running PHP 8.3 with OPcache enabled is the solid current default. OPcache caches compiled PHP bytecode in memory so the same script does not get re-parsed on every request, and this matters regardless of which web server is in front of it.
You can check what is actually active on your install with wp-cli:
wp cli info
wp cache typewp cli info reports the PHP version and other environment details, and wp cache type (when an object cache drop-in is installed) confirms whether Redis, Memcached, or the default database-backed cache is in use. Many Redis object cache plugins add their own wp-cli commands as well, which is worth checking if you are unsure whether persistent object caching is actually active versus just installed.
Cloudflare and the edge layer
None of this happens in isolation from what sits in front of the origin. Running Cloudflare ahead of any of these three servers adds edge caching, a WAF, bot mitigation, DDoS protection, Universal SSL, and HTTP/3, all before a request even reaches your web server. Keeping the origin IP unpublished behind Cloudflare matters specifically for DDoS resilience, since an attacker who cannot find the real server cannot target it directly. This layer is complementary to, not a replacement for, whatever full-page and object caching your web server handles.
The takeaway
Apache is forgiving and compatible but heavier under load. Nginx is efficient but breaks WordPress’s assumption that .htaccess just works. LiteSpeed combines Nginx-style efficiency with Apache-style .htaccess compatibility, and its native page cache integration through the LiteSpeed Cache plugin removes a layer of manual configuration that Nginx and Apache stacks usually require. If you are evaluating hosts, ask less about which server they run and more about how full-page caching, object caching, and PHP processing are actually wired together, since that combination is what determines whether your site feels fast under real traffic. ServerBorn runs LiteSpeed with Redis object caching and Cloudflare at the edge specifically because that combination minimizes the configuration gaps described above.