Apache and Nginx are the two dominant web servers on the internet. Apache has been around since 1995 and powered the early web. Nginx arrived in 2004, designed from the ground up to solve performance problems that Apache struggled with at scale. Both can serve WordPress sites. They are not equally suited to it.
This post covers how each server handles requests, how they differ in practice for WordPress workloads, and why the architectural differences matter more than benchmarks.
How Apache handles requests
Apache uses a process or thread-based model. Each incoming connection is handled by a dedicated worker – either a separate process or a separate thread depending on the MPM (Multi-Processing Module) configuration.
The most common configurations are:
Prefork MPM – spawns a pool of processes, each handling one connection at a time. Simple and stable, but memory-heavy. Each process carries the full Apache memory footprint regardless of whether it is actively doing work.
Worker MPM – uses threads instead of processes. More memory-efficient than Prefork, but PHP is not always thread-safe, which is why many Apache/PHP setups still use Prefork.
Event MPM – an improvement on Worker that handles keep-alive connections more efficiently by handing them off to a dedicated thread rather than tying up a worker.
The fundamental characteristic of Apache’s model is that each connection consumes a worker for its entire duration. Under high concurrency, this becomes a resource problem. A thousand simultaneous connections require a thousand workers.
Apache also has a feature called .htaccess – per-directory configuration files that allow folder-level overrides of server configuration. WordPress uses .htaccess extensively for permalink rewriting. It is convenient but carries a cost: Apache checks for .htaccess files on every request, reading from disk at each directory level in the path. On a site with a deep directory structure, this adds filesystem reads to every request.
How Nginx handles requests
Nginx uses an event-driven, asynchronous architecture. A small number of worker processes handle all connections through a non-blocking event loop. One worker process can manage thousands of simultaneous connections without spawning new processes or threads.
This model is significantly more memory-efficient under load. While Apache might have hundreds of worker processes sitting in memory waiting for connections, Nginx handles the same traffic with a handful of workers and far less memory consumption per connection.
Nginx does not have an equivalent to .htaccess. All configuration lives in the server configuration files. This means there is no per-request filesystem check for configuration overrides – Nginx reads its configuration once at startup and keeps it in memory.
The tradeoff is that Nginx configuration requires server-level access. Users on shared hosting cannot drop a configuration file into a directory and have it take effect the way they can with Apache and .htaccess.
How PHP fits in
Neither Apache nor Nginx executes PHP natively. Both need PHP-FPM (FastCGI Process Manager) or a similar mechanism to run PHP code.
With Apache, a common setup uses mod_php, which embeds the PHP interpreter directly into each Apache worker process. This means every Apache process carries the PHP interpreter in memory, even for requests that serve static files. It is simple to configure but wasteful – serving an image does not need a PHP interpreter, but the process serving it has one loaded anyway.
The more modern Apache setup also uses PHP-FPM through FastCGI, similar to Nginx. This is more efficient because PHP workers are separate from Apache workers, and static files can be served without touching PHP at all.
With Nginx, PHP-FPM via FastCGI is the standard configuration. There is no mod_php equivalent. Nginx passes PHP requests to PHP-FPM through a Unix socket or TCP connection and serves the response back to the client. Static files are served directly by Nginx without involving PHP at all.
Both servers handle PHP-FPM well. The difference is that mod_php (the embedded approach) is still widely used with Apache and creates the overhead described above, while Nginx never had this option and therefore never accumulated sites running the less efficient configuration.
WordPress-specific considerations
Permalink rewriting
WordPress uses pretty permalinks by default – URLs like /blog/my-post/ instead of /?p=123. These URLs do not correspond to actual files on disk. The web server needs to rewrite them to index.php so WordPress can handle them.
With Apache, this is done via .htaccess rules that WordPress writes automatically. With Nginx, the rewriting is done in the server configuration with a try_files directive. The Nginx approach is more efficient because the rewriting rule is loaded in memory at startup, while Apache checks the .htaccess file on every request.
Static file serving
A WordPress site serves a mix of PHP-generated pages and static assets – CSS, JavaScript, images, fonts. Nginx’s event-driven architecture handles static file serving particularly efficiently. Static files are read from disk and sent to the client without blocking other connections.
Under high concurrency, the difference between Nginx and Apache serving static files is meaningful. Nginx can handle a large number of simultaneous static file requests with minimal memory overhead. Apache with Prefork MPM requires a worker process per connection, which limits how many simultaneous static file requests can be handled before memory becomes a constraint.
Concurrent traffic
WordPress sites can experience traffic spikes – a post going viral, a sale going live, a newsletter going out. At peak concurrency, Nginx’s architecture handles the load more gracefully than a process-per-connection model. Nginx can queue and process more simultaneous connections without exhausting memory or spawning excessive processes.
This matters on shared hosting in particular, where memory is a finite resource shared across multiple sites. More memory-efficient web server architecture means more capacity available per account.
WooCommerce
WooCommerce generates significant server load due to its database-heavy operations and the fact that cart, checkout, and account pages cannot be cached. These pages require PHP execution on every request. The web server itself is less of a bottleneck here than PHP-FPM and the database, but Nginx’s efficient handling of concurrent connections means more requests can queue for PHP-FPM without the web server itself becoming a constraint.
Admin panel performance
The WordPress admin is never cached and involves heavy database activity. Every admin page load goes through PHP. Nginx handles the proxying to PHP-FPM with low overhead, keeping admin performance as fast as the PHP execution itself allows rather than adding server-level latency on top.
LiteSpeed: the third option
LiteSpeed Web Server (LSWS) is worth mentioning because it is common in the shared hosting industry, particularly on stacks running cPanel and CloudLinux. LiteSpeed is a commercial web server that is drop-in compatible with Apache configuration and .htaccess files, which makes it easy for hosts to switch from Apache without breaking existing customer sites.
LiteSpeed’s performance characteristics are closer to Nginx than Apache – it uses an event-driven architecture rather than a process-per-connection model, handles concurrency efficiently, and supports HTTP/3 and QUIC natively. It also has its own caching layer called LiteSpeed Cache, which integrates tightly with the LiteSpeed Cache WordPress plugin and can deliver cached pages at the web server layer without involving PHP.
The main limitation is licensing cost. LiteSpeed is proprietary software with per-server licensing fees, unlike Nginx and Apache which are open source. For hosting providers running large fleets, this adds up. CloudLinux bundles LiteSpeed licensing with its own subscription, which is why the cPanel + CloudLinux + LiteSpeed stack is common – the commercial components are packaged together.
For WordPress sites on a LiteSpeed host, performance is generally good and the LiteSpeed Cache plugin is one of the better caching solutions available. The .htaccess compatibility means migrations from Apache hosts work without rewriting configuration. The tradeoff is that you are dependent on a proprietary server with a vendor-controlled roadmap and licensing structure.
Apache's advantages
Apache is not without genuine advantages. .htaccess is the biggest one for shared hosting environments where users need to control server behavior without server-level access. WordPress’s automatic .htaccess management makes Apache setups largely self-configuring for common needs.
Apache also has a larger ecosystem of modules and longer community history. For specific use cases – complex authentication setups, certain proxying configurations, legacy applications – Apache’s module ecosystem may have a ready-made solution that Nginx requires more custom configuration to replicate.
If you are migrating from a host that runs Apache and have custom .htaccess rules for redirects, authentication, or custom headers, those rules need to be translated to Nginx syntax before migrating. Most common .htaccess rules have direct Nginx equivalents, but it requires awareness.
Why Hostney runs Nginx
Hostney runs OpenResty, a custom-patched distribution of Nginx extended with LuaJIT scripting, with HTTP/3 and QUIC enabled across the entire fleet. OpenResty uses the same core architecture as Nginx but adds the ability to run Lua code directly inside the request processing pipeline – before the request reaches PHP, after the response is generated, or at any other stage. This is how our bot detection, proof-of-work challenges, and edge rate limiting run inline with every request at microsecond latency without adding a separate proxy layer. It is standard Nginx under the hood with significantly more programmability at the edge.
OpenResty’s memory efficiency and connection handling make it the better fit for a shared hosting environment where many sites share server resources. Lower per-connection memory overhead means more capacity available per server, which benefits every site on the platform.
The lack of per-request .htaccess filesystem checks is a meaningful performance advantage at scale. On a server hosting hundreds of WordPress sites, eliminating those filesystem reads across every request adds up.
PHP-FPM via Unix socket is the standard configuration on all Hostney servers. OpenResty communicates with PHP-FPM through the socket with minimal overhead. Static files are served directly without involving PHP at all, keeping PHP workers available for requests that actually require them.
WordPress permalink rewriting is handled in the server configuration rather than .htaccess, which means it is in memory and applied without disk reads. Custom redirects that would normally go in .htaccess can be managed through the control panel’s redirect manager, which writes them to the server configuration directly.
Legacy Apache support
For sites that depend on Apache-specific behavior – complex .htaccess logic, mod_rewrite rules that do not translate cleanly to Nginx, or legacy applications built around Apache assumptions – Hostney allows switching the web server frontend on a per-subdomain basis. This is configurable under Hosting > Subdomains in the control panel. Each subdomain can run either OpenResty or Apache independently, so you can run a modern WordPress site on OpenResty while keeping a legacy application on Apache on the same account without conflict.
The practical answer
For most WordPress sites, the choice of web server is not something you control – it is determined by your hosting provider. If you are evaluating hosting providers, Nginx is the better choice for WordPress for the reasons covered above: more efficient concurrency handling, lower memory overhead, no per-request .htaccess checks, and clean PHP-FPM integration.
The performance difference is most visible under load. A lightly-trafficked site on well-configured Apache will not feel meaningfully different from the same site on Nginx. A site experiencing a traffic spike, handling WooCommerce concurrency, or sharing server resources with many other sites will see the architectural difference more clearly.
Apache is not a bad web server. It powered the web for decades and continues to run many sites successfully. For WordPress specifically, Nginx’s architecture aligns better with the workload – high concurrency, mixed static and dynamic content, and the memory constraints of shared infrastructure.