TL;DR
- For most PHP sites the Nginx-versus-Apache choice moves performance less than the layers around it: PHP-FPM, OPcache, and a full-page cache.
- The real architectural difference is concurrency. Nginx’s event loop holds thousands of idle connections cheaply; Apache’s process/thread model uses more memory under the same load.
- Run PHP through PHP-FPM on either server.
mod_phpties a PHP interpreter to every Apache process and is the single biggest legacy performance mistake. - “Nginx in front of Apache” is a real pattern, not a cop-out: Nginx terminates TLS and serves static files, Apache keeps
.htaccesscompatibility for the app.
Every few months someone asks me whether they should “switch to Nginx to make the site faster,” and the honest answer is usually no — not because Nginx is slow, but because the web server is rarely where their time is going. I have watched a site cut its response time in half by turning on OPcache and a full-page cache while staying on the exact same Apache it started with. The server software was never the bottleneck.
So this is not a “which one wins” article, because framed that way the question barely matters. It is about where web-server performance actually comes from, what genuinely differs between Nginx and Apache, and how to choose without treating it as a branding decision.
The difference that is real: concurrency
Apache and Nginx handle connections with fundamentally different models, and this is the one place the choice has real performance consequences.
Apache, in its common configurations, maps connections onto processes or threads. Under load with many slow or idle clients — mobile networks, keep-alive connections, long downloads — each one occupies a worker, and memory use climbs with concurrency. Nginx uses an event-driven loop: a small fixed set of worker processes multiplexes thousands of connections, and idle ones cost almost nothing. That is why Nginx shines as a reverse proxy and at high concurrency, and why it became the default in front of APIs and CDNs.
For a site serving a few hundred concurrent users, both are comfortably fast. The difference shows up at the tail — high concurrency, lots of idle connections — not in the median request.
The layer that matters more: how PHP runs
mod_php is the legacy mistake
The old Apache default embeds a PHP interpreter in every Apache process, so each one carries PHP’s memory even when serving a static file. Run PHP through PHP-FPM instead — a separate, tunable pool of PHP workers that both Apache and Nginx talk to over FastCGI. This single change usually does more for throughput than switching web servers.
With PHP-FPM in place, the levers that actually move performance are mostly not the web server at all:
OPcache
Caches compiled PHP bytecode in memory. Often the largest single win, and frequently left off.
Full-page cache
Serving a cached HTML response skips PHP and the database entirely — the biggest win for content sites.
Object cache
Redis or Memcached cuts repeated database queries on dynamic pages.
FPM pool tuning
Right-size worker counts to your RAM so you neither starve nor swap under load.
For a WordPress site specifically, a full-page cache (FastCGI cache on Nginx, or a cache plugin like LiteSpeed or one fronted by Varnish) is the difference between rebuilding every page from PHP and the database on each hit and serving a static file in microseconds. That decision dwarfs the Nginx-versus-Apache one.
Where Apache still earns its place: .htaccess
Apache’s per-directory .htaccess files are both its compatibility superpower and a quiet performance cost. They let a plugin, a framework, or a shared-hosting user change rewrite and access rules without touching the central config — which is exactly why so much of the WordPress and legacy-PHP ecosystem assumes them. The cost is that Apache checks for .htaccess files on every request along the path. Nginx has no equivalent; its rules live in one central config, which is faster but means changes need a reload and server access.
If your application or host depends on .htaccess, that dependency is a real reason to keep Apache in the stack — not a failure to modernize.
Nginx in front of Apache: the pragmatic hybrid
You do not have to choose. A common production shape puts Nginx at the edge and Apache behind it: Nginx terminates TLS, serves static assets directly, and reverse-proxies dynamic requests to Apache, which runs the application with its .htaccess compatibility intact. You get Nginx’s connection handling and static-file speed at the front and Apache’s ecosystem compatibility at the back. Many managed WordPress hosts run something like this without advertising it.
A practical way to choose
Switching servers to fix speed
Before changing web servers, confirm OPcache, a full-page cache, and PHP-FPM are in place. They usually matter more.
Running mod_php in 2026
Embedding PHP in Apache processes wastes memory on every request. Move to PHP-FPM regardless of which server you keep.
No full-page cache on a content site
Rebuilding every page from PHP and the database on each hit is the most common avoidable bottleneck.
Tuning the wrong layer
Hand-tuning worker directives while the database does unindexed full scans optimizes the part that was not slow.
The short version: pick Nginx when the workload is high-concurrency, proxy-oriented, or API-driven, and when you control the server config. Keep Apache when you depend on .htaccess, run on shared hosting, or your team already operates it well. Then spend your real effort on caching, PHP-FPM, and the database — that is where the wins are.
FAQ
- Is Nginx faster than Apache?
- For high-concurrency and reverse-proxy workloads, Nginx’s event-driven model uses less memory and handles idle connections more efficiently. For typical traffic, both are fast, and OPcache, a full-page cache, and PHP-FPM affect real-world performance far more than the choice between them.
- Should I use mod_php or PHP-FPM?
- PHP-FPM, in nearly all cases. It runs PHP in a separate, tunable worker pool that both Apache and Nginx use over FastCGI, instead of embedding an interpreter in every web-server process. Moving from
mod_phpto PHP-FPM usually improves throughput more than changing web servers. - What is the biggest performance win for a WordPress site?
- A full-page cache. Serving a cached HTML response skips PHP and the database entirely, turning a multi-query page build into a static-file read. After that, OPcache and a Redis object cache are the next largest wins — all of which are independent of whether you run Nginx or Apache.
- Can I run Nginx and Apache together?
- Yes, and it is a common pattern. Nginx sits at the edge to terminate TLS and serve static files, then reverse-proxies dynamic requests to Apache, which runs the application and keeps
.htaccesssupport. You get Nginx’s connection handling with Apache’s compatibility.
Related articles
- Docker and WordPress: how containers simplify development makes it easy to benchmark these server choices in a reproducible stack.
- WordPress Bedrock with Docker locally and bare PHP in production covers the LiteSpeed full-page cache and deploy flow on real shared hosting.
