LiteSpeed, Nginx and Apache can all run WordPress well: what really separates them is page caching and how much server administration you are willing to do. LiteSpeed pairs Nginx’s event-driven design with Apache’s .htaccess compatibility and a server-level cache you control from WordPress; Nginx shines when a technical team owns its configuration; Apache remains the most compatible option, at the cost of heavier resource use under load.
Comparison current as of 13 October 2026. We have not published any in-house benchmark, because speed test results depend too heavily on the site being measured. Technical facts link to each project’s official documentation.
Key takeaways
- Caching matters more than the server: a page served from a page cache is fast on all three; without caching, PHP and the database are what slow WordPress down.
- Apache reads
.htaccessfiles on every request, which makes it flexible but heavier; Nginx ignores them entirely. - LiteSpeed is event-driven like Nginx and understands Apache’s
.htaccessrules; its LSCache cache is driven by the free LiteSpeed Cache plugin. - HTTP/3 is built into LiteSpeed, experimental in Nginx and missing from Apache httpd 2.4 (a CDN usually fills the gap).
- On 12 October 2026, W3Techs found Nginx on 30.6% of sites with a known web server, Apache on 21.7% and LiteSpeed on 14.1%.
What does a web server actually do for WordPress?
The web server accepts every browser request, returns static files (images, CSS, JavaScript) directly and hands dynamic pages to PHP, which runs WordPress and queries the database. It also handles HTTPS encryption, compression, HTTP/2 and HTTP/3, and the rewrite rules behind pretty permalinks.
In other words, the web server does not run WordPress itself: it orchestrates. How it handles concurrent connections, talks to PHP and caches pages decides how well your site copes with a traffic spike. That is why the choice matters most for busy sites and for sites with many uncacheable requests, such as a WooCommerce store.
How do Apache, Nginx and LiteSpeed differ under the hood?
Apache handles connections with processes or threads, depending on the MPM module in use, and reads .htaccess files on the fly. Nginx and LiteSpeed are event-driven: a handful of processes juggle thousands of connections. LiteSpeed adds compatibility with Apache configuration and .htaccess files.
Apache HTTP Server: the flexible veteran
Apache is WordPress’s historic home. Its signature feature is the .htaccess file: any folder can carry its own rules (redirects, permalinks, access control), and many WordPress plugins write to it automatically. Apache offers several connection-handling modules: prefork (one process per connection), worker and event (threaded and leaner).
That flexibility has a price, which the Apache documentation acknowledges itself: when .htaccess files are allowed, the server looks for them in every directory and reloads them on every request, which costs performance. Under heavy load, Apache also uses more memory than event-driven servers.
Nginx: the choice of large sites
Nginx was built to hold huge numbers of concurrent connections with little memory. It does not read .htaccess files: every rule lives in the server configuration, which must be reloaded after changes. For WordPress you add a try_files directive that routes permalinks to index.php, and PHP runs through PHP-FPM.
It is an excellent fit for a team that manages its own server, and less comfortable on shared hosting: a plugin that adds a rule to .htaccess (security, redirects, caching) has no effect under Nginx, so those rules must be translated by hand.
LiteSpeed: Nginx’s architecture, Apache’s compatibility
LiteSpeed Web Server is event-driven and marketed by its vendor as a drop-in Apache replacement: it reads Apache configuration files and .htaccess rules, so WordPress plugins that rely on them work unchanged. PHP runs through LSAPI, LiteSpeed’s native PHP interface.
There are two editions. LiteSpeed Enterprise is commercial. OpenLiteSpeed is free and open source, but it only supports mod_rewrite-style rewrite rules and, according to its documentation, must be restarted before changes to those rules take effect. On managed hosting, your host takes care of that.
| Criterion | Apache | Nginx | LiteSpeed |
|---|---|---|---|
| Architecture | Processes or threads (prefork, worker, event MPMs) | Event-driven | Event-driven |
.htaccess files | Yes, re-read on every request | No (rules live in the server config) | Yes (Enterprise); rewrite rules only, after a restart (OpenLiteSpeed) |
| How PHP runs | mod_php or PHP-FPM | PHP-FPM | LSAPI |
| WordPress page cache | PHP plugin or a proxy (Varnish) | FastCGI cache module + purge plugin | Built-in LSCache + LiteSpeed Cache plugin |
| HTTP/3 | Not available in httpd 2.4 | Experimental module since 1.25.0 | Built in |
| Licence | Open source (Apache 2.0) | Open source (BSD) | Commercial (Enterprise) or open source (OpenLiteSpeed) |
| Share of sites (W3Techs, 12 Oct 2026) | 21.7% | 30.6% | 14.1% |
Which web server is fastest for WordPress?
With a well-tuned page cache, all three serve a WordPress page in a few milliseconds: the cache, not the software, delivers most of the gain. Differences show up on uncacheable pages (cart, account, admin) and under heavy concurrency, where event-driven servers use less memory.
Be wary of spectacular benchmarks: vendor tests often measure static files or an empty page, in conditions that look nothing like your site. A slow WordPress site is almost always slow because of a heavy theme, too many plugins, expensive database queries or third-party scripts, and no web server fixes those. Our guide to speeding up WordPress covers them one by one.
What really sets LiteSpeed apart for WordPress is integration: the cache lives inside the server, the plugin knows exactly which pages to purge when you publish, and everything is set from the dashboard without touching server configuration.
How does each server cache WordPress pages?
On Apache, page caching usually relies on a PHP plugin that writes HTML files, or on a proxy such as Varnish in front. On Nginx, you enable FastCGI caching and a plugin handles purges. On LiteSpeed, LSCache is built into the server and controlled by the free LiteSpeed Cache plugin.
Apache: a caching plugin or Varnish
Plugins such as WP Super Cache or W3 Total Cache generate HTML copies of your pages; depending on their mode, Apache serves those files directly through .htaccess rules, or PHP starts up to read them. Some hosts go further and put Varnish in front of Apache, which adds another layer to configure and purge.
Nginx: FastCGI cache
Nginx can keep PHP-FPM responses in memory or on disk with its FastCGI cache module. It is very effective, but purging is not built into the open-source version: you need a WordPress plugin, often an extra module, plus rules so that logged-in users and the cart are never cached.
LiteSpeed: LSCache and the LiteSpeed Cache plugin
On LiteSpeed, the LiteSpeed Cache plugin talks directly to the server cache: automatic purges on publish, exclusions for sensitive pages, a separate cache for logged-in visitors and, on the Enterprise edition, ESI to keep one dynamic block (cart, admin bar) inside a cached page. The plugin also optimises images, CSS and JavaScript. Its server-cache features need a LiteSpeed server or the QUIC.cloud CDN. Our LiteSpeed Cache setup guide walks through the settings.
Does HTTP/3 change the picture?
HTTP/3, standardised by the IETF as RFC 9114, swaps TCP for QUIC: connections open faster and cope better with packet loss, which mostly helps mobile visitors. LiteSpeed supports it natively, Nginx offers it through an experimental module, and Apache httpd 2.4 does not implement it.
For Nginx, the HTTP/3 module documentation has described it as experimental since it arrived in version 1.25.0, and it must be enabled at build time. For Apache, the official 2.4 module list includes mod_http2 but no HTTP/3 module, so Apache sites usually get HTTP/3 from a CDN in front of the server.
HTTP/3 will not turn a slow site into a fast one, but it shortens connection setup, a step every first-time visitor pays for.
Which server should you pick for your situation?
If someone else runs the server, focus on getting a host with a ready-tuned page cache: LiteSpeed with LSCache is the simplest combination for WordPress. If you run your own VPS, Nginx is an excellent choice provided you are comfortable with its configuration. Apache still earns its place through compatibility.
| Your situation | Suggested server | Why |
|---|---|---|
| Business site, blog or store on shared hosting | LiteSpeed | Server cache driven from WordPress, .htaccess-compatible, no server config to write |
| WooCommerce store with many uncacheable pages | LiteSpeed or Nginx | Event-driven, lower memory use under concurrency |
| VPS run by a technical team | Nginx (or OpenLiteSpeed) | Fine-grained config, open source, extensively documented |
| App that depends on specific Apache modules | Apache | Maximum compatibility with the Apache ecosystem |
| Site already behind a CDN that handles HTTP/3 | Any | The CDN handles the protocol; focus on caching |
How can you tell which web server your site runs on?
The quickest way is to read the server HTTP header your site returns. It says LiteSpeed, nginx or Apache, unless your host hides it or a CDN such as Cloudflare sits in front, in which case you will see the CDN’s name instead.
From a terminal, this command shows the server and, on LiteSpeed, the cache status (replace the address with your own):
curl -sI https://www.example.com/ | grep -i -E "^server|x-litespeed-cache|alt-svc"An x-litespeed-cache: hit header confirms the page came from the LiteSpeed cache; an alt-svc header mentioning h3 means the server offers HTTP/3. Inside WordPress, the server software is also listed under Tools › Site Health › Info › Server.
Moving from Apache to LiteSpeed: what should you plan for?
Switching from Apache to LiteSpeed rarely requires changes to the site, because LiteSpeed reads .htaccess rules. The main jobs are replacing your old caching plugin with LiteSpeed Cache, checking the headers and testing sensitive pages. Allow about an hour of checks for a typical site.
- Take a full backup (files and database) first.
- Deactivate your old caching plugin (WP Super Cache, W3 Total Cache, WP Rocket…) so two caches do not fight, and remove the rules it added to
.htaccess. - Install LiteSpeed Cache and enable page caching with the default settings.
- Check the headers with the command above: load the same page twice, and the second response should say
hit. - Test pages that must never be cached: cart, checkout, customer account, forms.
- Measure before and after with PageSpeed Insights on mobile, noting TTFB and LCP.
If you are changing hosts to move to LiteSpeed, follow our method to migrate a WordPress site without downtime, or let us do it: migration is free at Hosterwise.
Why did Hosterwise choose LiteSpeed?
We specialise in WordPress and WooCommerce hosting, and our servers run LiteSpeed Enterprise, the commercial edition, not OpenLiteSpeed. It lets us ship a ready-to-use server cache, driven from WordPress, without asking customers to write a single line of server configuration. It reads .htaccess files the way Apache does, so plugins that write their rules there work unchanged, and it supports ESI to keep a dynamic block such as the cart inside a cached page. Add HTTP/3, a Redis object cache available on every plan, and the CyberPanel control panel.
That choice does not replace optimising the site itself, and a well-run Nginx host can serve you just as well. To compare providers on checkable criteria, see our WordPress hosting comparison.
If you want to see what LiteSpeed does for your own site, our LiteSpeed WordPress hosting includes LSCache, HTTP/3, free migration and a 30-day money-back guarantee on your first hosting order. Plans start at €6.99 per month excluding VAT on a 48-month term, or €14.99 per month with no commitment; full details are on our pricing page.
Frequently asked questions
Is LiteSpeed faster than Nginx for WordPress?
Both are high-performance, event-driven servers. For WordPress, LiteSpeed’s edge comes mainly from its built-in cache, driven by the LiteSpeed Cache plugin, and from .htaccess compatibility. With a well-configured cache on both sides, the speed difference your visitors notice is small.
Can Nginx read .htaccess files?
No. Nginx ignores .htaccess files: rewrite, redirect and access rules must go in the server configuration, followed by a reload. WordPress plugins that write to .htaccess therefore have no effect on Nginx.
Does the LiteSpeed Cache plugin work on Apache or Nginx?
Its optimisation features (images, CSS, JavaScript) work on any server. Its page cache and other LiteSpeed-exclusive features, however, require a LiteSpeed server (OpenLiteSpeed or Enterprise), LiteSpeed-powered hosting or the QUIC.cloud CDN.
What is the difference between OpenLiteSpeed and LiteSpeed Enterprise?
OpenLiteSpeed is the free, open-source edition; LiteSpeed Enterprise is commercial. Enterprise reads Apache configurations and .htaccess files the way Apache does; OpenLiteSpeed only supports rewrite rules and needs a restart to apply changes to them. ESI is not available in OpenLiteSpeed. Hosterwise runs LiteSpeed Enterprise, so ESI is available and your .htaccess files are read just as Apache would read them.
Is Apache still a good choice for WordPress in 2026?
Yes. WordPress.org still recommends Apache alongside Nginx, and it works perfectly well with a page cache. It simply uses more memory under heavy load and lacks HTTP/3, which you would then get from a CDN.
Can switching web servers break my site?
Moving from Apache to LiteSpeed is usually seamless thanks to .htaccess compatibility. Moving to Nginx means translating your .htaccess rules into the server configuration. Either way, back up and test on a copy before switching.

