Web Servers Explained: Apache, Nginx, and LiteSpeed — Concurrency Models and Real Hosting Stacks

What a Web Server Actually Does (Not Just "Serves Websites")

Every explanation of web servers starts with "software that serves web content." That description is accurate in the same way that "a car moves you from place to place" is accurate. It misses everything that matters. A web server performs five distinct jobs in sequence, and each job has a different performance profile, different failure modes, and different configuration options that affect your WordPress site.

Apache vs Nginx vs LiteSpeed: The Three Engines That Power WordPress

These three web servers power over 75% of all websites. They share the same job — accepting HTTP requests and returning responses — but they make fundamentally different architectural choices about how to do it. Those choices produce different performance characteristics under different conditions, different compatibility requirements, and different optimization ceilings. The table below is not just a feature list. Read the implications column — that is where the practical decisions live.

PHP Execution Methods: The Part Most Comparisons Skip

The web server handles the HTTP layer. What PHP actually runs on, and how the web server hands off to PHP, is a separate decision that affects WordPress performance as much as the web server choice itself. There are four methods, and two of them should never appear in a production WordPress setup.

The correct combination for a modern WordPress stack is: Nginx or LiteSpeed as the web server, PHP-FPM (or LSAPI for LiteSpeed) as the PHP execution method. This combination gives you event-driven connection handling at the web server layer, process isolation and pool management at the PHP layer, and no dependency between web server crashes and PHP crashes. I have seen multiple sites go down because mod_php was running on Apache and a single PHP infinite loop caused the Apache worker to hang, blocking all connections — the web server and PHP shared the same process. With PHP-FPM, PHP hanging would have killed one FPM worker and been replaced by another.

Event-Driven vs Process-Based: The Architecture That Defines Concurrency

Most hosting comparisons note that "Nginx uses less memory." Almost none explain why. The why is the most important thing to understand about web servers — because it is not a tuning difference or a configuration difference. It is a fundamental architectural choice made at design time that cannot be optimized away.

Apache's Process-Based Model

Apache in prefork mode creates a new process for every incoming connection. A process is a complete copy of the Apache runtime: its own memory space, its own file descriptors, its own copy of loaded modules. When 200 visitors connect simultaneously, Apache maintains 200 processes. Each process sits in memory doing one of three things: handling an active request, waiting for a keep-alive request on an existing connection, or waiting to be assigned a new connection.

The memory cost is the first problem. The blocking behavior is the second. While a process is waiting for PHP to finish executing — which might take 300ms on a slow database query — that process is blocked. It cannot accept another connection. It cannot do anything except sit there waiting. Apache's response: increase the number of processes. More processes means more blocking capacity. But more processes means more RAM. The two problems compound each other.

Apache's worker and event MPMs improve on prefork by using threads instead of separate processes for connections. Threads within a process share memory, making each connection cheaper. But the fundamental limit remains: the concurrency ceiling is still tied to the number of threads and processes, not to the number of connections the kernel can handle.

Nginx's Event-Driven Model

Nginx runs one worker process per CPU core. That is typically 4-16 worker processes on a modern server, regardless of how many simultaneous connections are active. Each worker process runs a single-threaded event loop that uses the Linux kernel's epoll mechanism to monitor thousands of open file descriptors (connections) simultaneously.

Here is the critical difference: when Nginx is waiting for PHP-FPM to finish processing — those same 300ms the Apache process is blocked — Nginx's event loop is not blocked. It loops back and checks if any other connection has data ready to read or write. A single Nginx worker can be managing 10,000 keep-alive connections while also forwarding 100 PHP requests to PHP-FPM and simultaneously serving static files from 500 ongoing downloads. None of these operations block the others because all I/O is non-blocking: Nginx registers interest in the file descriptor and continues to the next event, returning to that file descriptor when the kernel signals it has data.

What This Means in Practice for WordPress

For a WordPress blog that handles 50 concurrent visitors on a good shared hosting plan, the concurrency model difference is invisible. Both Apache and Nginx serve the traffic comfortably. The difference emerges under three conditions: traffic spikes, slow PHP execution, and keep-alive connections from modern browsers.

A news site that gets linked on a major social platform goes from 50 to 2,000 concurrent visitors in 90 seconds. Apache spawns processes until it hits MaxRequestWorkers, then new connections queue and wait for a worker to free up. Response times degrade from 200ms to 8 seconds as the queue grows. Nginx's event loop continues handling 2,000+ connections within the same workers it was using at 50 concurrent visitors. The bottleneck shifts to PHP-FPM pool size and database capacity — not the web server. Understanding which layer is the actual bottleneck is the entire point of knowing the hosting infrastructure at this level of detail.

Reverse Proxy Architecture: Why the Fastest Stacks Use Two Web Servers

The highest-performing WordPress hosting stacks do not choose between Apache and Nginx. They run both. Nginx in front handles connections, static files, SSL termination, and load balancing. Apache in the backend handles PHP via mod_php or PHP-FPM, .htaccess processing, and application logic. Each server does what it is best at. This is the reverse proxy architecture, and once you understand it, every other web server setup looks like a compromise.

Static File Offloading

Static file offloading is the most immediately impactful benefit of the reverse proxy setup. In a pure Apache setup, every request — including a request for a 5KB CSS file — goes through an Apache process. In a reverse proxy setup, Nginx handles static file requests entirely, never touching the Apache backend. Nginx's static file serving with sendfile() is extremely fast and extremely cheap in terms of server resources. The Apache backend only sees PHP requests.

I have seen this change measured in practice: a WordPress site that was spending 40% of Apache's worker capacity serving static files (images, CSS, JS) moved to an Nginx-in-front configuration. Immediately, Apache's MaxRequestWorkers utilization dropped by 40% under identical traffic. The same hardware handled significantly more concurrent PHP requests because Apache workers were no longer occupied serving static files.

Load Balancing

In an Nginx reverse proxy setup, the upstream configuration block becomes a load balancer with one additional line:

upstream wordpress_backend {
    # Default: round-robin distribution
    server 10.0.0.1:80 weight=3;   # App server 1 (3x traffic share)
    server 10.0.0.2:80 weight=1;   # App server 2 (1x traffic share)
    server 10.0.0.3:80 backup;     # Failover only — used when 1 and 2 are down

    # Least-connections algorithm (better for PHP with variable response times)
    least_conn;

    # Keepalive connections to backend (reduces connection overhead)
    keepalive 32;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://wordpress_backend;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
    }
}

This configuration scales WordPress horizontally. Add a third application server and update the upstream block — no changes to PHP, no changes to WordPress, no changes to the database configuration. Cloudways uses this exact architecture on its managed WordPress plans. ScalaHosting's high-tier managed VPS plans offer similar configurations on request. Understanding this architecture tells you exactly what you are paying for when a managed host charges premium prices: it is this infrastructure, configured and maintained for you.

Nginx FastCGI Cache as a Reverse Proxy for PHP

Nginx can also act as a reverse proxy for PHP-FPM in a single-server configuration, adding a page cache layer entirely outside WordPress:

# Define cache storage location and size
fastcgi_cache_path /var/run/nginx-cache levels=1:2
    keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

server {
    location ~ \.php$ {
        # Try cache first
        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
        fastcgi_cache_bypass $skip_cache;
        fastcgi_no_cache $skip_cache;
        add_header X-Cache $upstream_cache_status;

        # Forward to PHP-FPM
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
        include fastcgi_params;
    }
}

# Skip cache for logged-in users and WooCommerce sessions
map $http_cookie $skip_cache {
    default 0;
    "~*wordpress_logged_in" 1;
    "~*woocommerce_cart_hash" 1;
    "~*wp-postpass" 1;
}

The X-Cache header this configuration adds tells you whether any request is served from Nginx's cache (HIT) or from PHP-FPM (MISS). This is a no-plugin page cache that operates at a lower level than any WordPress cache plugin. The tradeoff compared to plugins like WP Rocket: cache invalidation requires either a server-side script or a plugin like Nginx Helper to trigger purge on WordPress publish events. The caching guide covers how this server-level cache integrates with the full six-layer cache stack.

HTTP/2 and HTTP/3: What Changed and Why Your Server Version Matters

HTTP/1.1 has been the web's protocol since 1997. HTTP/2 shipped in 2015. HTTP/3 is in production deployment now. Most hosting discussions treat these as background checkbox items — "supports HTTP/2: yes." They are not background items. HTTP/2 changed the entire optimization strategy for web performance, and HTTP/3 changes it again. If you are still domain-sharding assets or running JavaScript bundlers to reduce request count specifically because of HTTP/1.1 limits, you have already optimized for the wrong protocol.

Why HTTP/1.1 Forced Bad Optimization Practices

HTTP/1.1 allows one outstanding request per connection. Browsers work around this by opening up to 6 connections per domain. A page with 30 assets sends them in batches of 6, with each batch waiting for the previous batch to complete. Developers responded by inventing practices that no longer make sense under HTTP/2: bundling many JavaScript files into one (fewer requests), spriting CSS images into a single image file (one request instead of 40), domain sharding assets across cdn1.example.com and cdn2.example.com (12 connections instead of 6). Under HTTP/2, all of these optimizations are unnecessary and some are counterproductive. HTTP/2's multiplexing sends all 30 assets simultaneously over a single connection. Bundling creates large files with lower cache granularity — one change to any JavaScript module invalidates the entire bundle.

HTTP/2 Server Requirements

HTTP/2 requires HTTPS in practice (all browsers enforce this). For Apache, HTTP/2 requires the event MPM — which means mod_php is incompatible with HTTP/2 (mod_php requires the prefork MPM). Many legacy shared hosts running Apache with mod_php are therefore still serving HTTP/1.1 to every visitor. Verifying your protocol: open Chrome DevTools, go to Network tab, right-click the column headers, enable "Protocol." Every request should show h2 (HTTP/2) or h3 (HTTP/3). A request showing http/1.1 means either your server or the connection between a reverse proxy and your origin is still using HTTP/1.1.

HTTP/3 and QUIC: What Changes at the Transport Layer

HTTP/2 solved head-of-line blocking at the HTTP layer, but TCP itself still has head-of-line blocking. A single lost TCP packet stalls all HTTP/2 streams on that connection until retransmission. On a reliable wired connection this is rare. On mobile networks and congested Wi-Fi — which represent the majority of global traffic — packet loss is common. HTTP/3 replaces TCP with QUIC, a UDP-based protocol where each stream is independent at the transport layer. A lost packet for stream 5 does not stall streams 1-4 and 6-30. The practical result: HTTP/3 loads pages measurably faster on mobile networks and shows the largest improvements in regions with infrastructure limitations.

LiteSpeed natively supports HTTP/3 and enables it automatically. Cloudflare delivers HTTP/3 to visitors regardless of your origin server's protocol, because the protocol negotiation happens at the Cloudflare edge. This is one of the less-discussed advantages of putting Cloudflare in front of any WordPress site: even a site on a legacy Apache shared host running HTTP/1.1 at the origin level delivers HTTP/3 to browsers, because Cloudflare handles the modern protocol at the edge and communicates with your origin via HTTP/2 or HTTP/1.1 as appropriate. The CDN guide explains how Cloudflare's edge protocol handling differs from what your origin server delivers.

The LiteSpeed Cache Advantage: Server-Level Integration No Plugin Can Match

LiteSpeed Cache is the best free WordPress caching plugin. It is also a statement that requires qualification: LiteSpeed Cache is the best plugin on LiteSpeed web servers. On Apache or Nginx, most of its key features are disabled. The reason reveals something fundamental about how server-level caching works versus plugin-level caching — and why the two are not interchangeable.

Server-Level vs Plugin-Level Cache: The Architecture Difference

WP Rocket, W3 Total Cache, and most cache plugins operate at the PHP level. When a page request arrives, the web server passes it to PHP-FPM. PHP boots, loads WordPress, and runs the advanced-cache.php dropin — a hook that intercepts the request early in the WordPress bootstrap process. If a cached version exists, the dropin returns it immediately and WordPress stops loading. This is fast — the cache hit takes 5-15ms of PHP execution time and no database queries — but PHP still started, loaded, and ran code.

LiteSpeed Cache, when running on LiteSpeed web server, operates at the server level. The cached page is served by the web server directly, before PHP starts at all. The cache hit happens at the same layer as a static file: the web server reads the cached HTML from its internal cache store and returns it. PHP is never invoked. The speed difference is measurable: server-level cache hits typically complete in 1-5ms. Plugin-level cache hits take 10-30ms. For a high-traffic site, this difference compounds across thousands of requests per minute.

What LiteSpeed Cache Does That Nginx Cannot Do Automatically

Nginx FastCGI cache is also a server-level page cache, and it achieves similar performance to LiteSpeed Cache for simple cache hits. The difference is in cache management and WordPress integration. LiteSpeed Cache's plugin communicates directly with the LiteSpeed server via a shared-memory control channel to invalidate specific cache entries. When you publish a new post in WordPress, the plugin tells the server: purge the cached version of this URL, the homepage, and the category page that includes this post. This targeted purge happens in milliseconds, at the server level, without needing a separate cache-purging script or webhook.

With Nginx FastCGI cache, you need either the Nginx Helper plugin (which triggers a Nginx purge endpoint on WordPress events) or a custom bash script to handle invalidation. LiteSpeed Cache's integration is tighter and more reliable in practice, especially for WooCommerce stores where product page invalidation needs to trigger precisely when prices or inventory change.

LiteSpeed Cache Features Beyond Page Cache

Page cache is LiteSpeed Cache's flagship feature, but the plugin also includes: object cache via Redis or Memcached integration, image optimization (WebP conversion, lazy loading), CSS/JS minification and combination, critical CSS generation, browser cache header management, and CDN configuration. These features work on any web server. The object cache, CDN, and image optimization work on Apache and Nginx installations of LiteSpeed Cache. Only the page cache and LSAPI PHP integration require LiteSpeed web server. For a comprehensive look at how LiteSpeed Cache fits into the full caching stack, the WordPress caching guide breaks down all six cache layers and where LiteSpeed Cache addresses each.

Which Hosts Run LiteSpeed

LiteSpeed Enterprise requires a paid license from LiteSpeed Technologies. Hosting providers pay this license and pass the benefit to customers. The hosts most commonly associated with LiteSpeed shared hosting: A2 Hosting's Turbo plans, Hostinger on some plans, FastComet, NameHero, and Ultahost. On the VPS side, any host that lets you install OpenLiteSpeed on a self-managed VPS gives you LiteSpeed's performance at zero additional cost. ScalaHosting offers LiteSpeed on their managed VPS plans alongside Nginx and Apache options.

Real Hosting Stack Examples: Shared, Managed VPS, and Enterprise

The web server is one component of a hosting stack. Knowing the web server alone does not tell you how your WordPress site performs. Performance depends on the full stack: what sits in front of the web server, how PHP connects to the web server, how the database is configured, what caching layers exist, and what the hardware underneath everything looks like. Here is what the stack actually looks like at three distinct hosting tiers.

The gap between shared hosting and managed VPS is not primarily about hardware quality — both run on similar data center infrastructure. The gap is architectural. Shared hosting runs one web server process for hundreds of sites with no isolation between them. Managed VPS runs a dedicated PHP-FPM pool, dedicated Redis, and properly tuned MySQL for your site alone. This architectural difference is why a site running on ScalaHosting's $30/month managed VPS consistently outperforms the same site on a $15/month shared plan with nominally more disk space and bandwidth. The managed VPS guide explains exactly what "managed" means in practice and what you are paying for beyond the server hardware itself.

Web Server Configuration That Affects WordPress Speed

The choice of web server is a decision you make once. Configuration is ongoing. Most WordPress performance problems I have traced in practice were not the web server software being wrong — they were the default configuration being unsuitable for the actual workload. Default configurations are tuned for a generic setup, not for a WordPress site with 20 plugins, a WooCommerce store, and 500 concurrent visitors.

The PHP-FPM Pool Sizing Formula

The most common performance failure I have encountered on VPS setups is an undersized PHP-FPM pool. The default pm.max_children = 5 means only 5 PHP requests can execute simultaneously. On a site with any real traffic, this creates a queue. Requests wait in the queue until a PHP-FPM worker frees up. TTFB spikes from 200ms to 3+ seconds during any traffic burst, not because the server is overloaded, but because the PHP queue is full. The fix:

# Step 1: Measure average PHP process memory on your server
# Run this after your site has been under normal traffic for 30+ minutes:
ps aux | grep php-fpm | awk '{print $6}' | sort -n | tail -10

# Typical results: 40-80 MB per PHP process for WordPress
# Higher for WooCommerce (60-120 MB) or heavy plugins

# Step 2: Calculate max_children
# Formula: max_children = (available_RAM_for_PHP) / (average_PHP_process_MB)
# Example: 2GB VPS, 512MB for OS/web server/Redis, leaves 1.5GB for PHP
# average PHP process = 60 MB
# max_children = 1500 / 60 = 25

# Step 3: Configure in /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 25       # Maximum PHP workers
pm.start_servers = 5       # Start with 5 workers
pm.min_spare_servers = 3   # Keep at least 3 idle workers ready
pm.max_spare_servers = 10  # Don't keep more than 10 idle workers
pm.max_requests = 500      # Recycle workers after 500 requests (prevents memory leaks)
pm.process_idle_timeout = 10s

# Step 4: Verify the change took effect
systemctl reload php8.2-fpm
# Check active workers:
ps aux | grep -c php-fpm

Gzip and Brotli Compression

Text compression is the highest-impact, zero-risk configuration change for most WordPress setups. Enabling gzip on HTML, CSS, JavaScript, and XML responses reduces transfer size by 60-80%. Most servers have gzip available but disabled or misconfigured. Brotli is a newer compression algorithm that achieves 10-25% better compression than gzip at equivalent CPU cost. Nginx requires the ngx_brotli module (not in default builds). LiteSpeed includes brotli natively. Apache uses mod_brotli.

# Enable gzip (available in default Nginx)
gzip on;
gzip_types
    text/html text/plain text/css
    application/javascript application/json
    application/xml text/xml
    font/woff2;
gzip_min_length 1024;    # Do not compress files smaller than 1KB
gzip_comp_level 6;       # Level 1-9. Level 6 is the best CPU/compression tradeoff.
gzip_vary on;            # Add Vary: Accept-Encoding header

# Verify compression is working:
curl -sI --compressed https://yourdomain.com/ | grep -i content-encoding
# Expected: content-encoding: gzip (or br for brotli)

How to Choose the Right Web Server for Your WordPress Site

The honest answer for most WordPress owners: you do not choose your web server. Your host does. The decision is made when you choose a hosting provider. So the real question is: given that different hosts run different web servers, which host-and-server combination is right for your situation?

Checking Your Current Web Server

# Method 1: Check HTTP response header
curl -sI https://yourdomain.com | grep -i "^server:"
# Examples:
# Server: Apache     — Apache web server
# Server: nginx      — Nginx web server
# Server: LiteSpeed  — LiteSpeed Enterprise
# Server: cloudflare — Cloudflare proxy (origin server hidden)

# Method 2: If behind Cloudflare, check via direct IP
# Get your origin IP from hosting panel, then:
curl -sI --resolve "yourdomain.com:443:YOUR.ORIGIN.IP" https://yourdomain.com \
  | grep -i "^server:"

# Method 3: From within WordPress via WP-CLI
wp eval 'echo $_SERVER["SERVER_SOFTWARE"];'

# Method 4: PHP phpinfo check
# Create test.php with: