Nginx vs Apache Performance on Shared Hosting

Choosing between Nginx and Apache based on a single requests-per-second chart often solves the wrong problem. On shared hosting, PHP limits, database contention, cache policy, and account quotas can dominate the web server choice.

A useful comparison measures the same workload under documented conditions. This guide creates a repeatable test plan, distinguishes cached traffic from application work, and turns results into questions your hosting provider can actually answer.

Define the question before measuring speed

Separate response latency from capacity under load. A fast request from one location tells you little about how a blog behaves when many readers arrive together. Likewise, a high throughput result is meaningless if errors or stale content account for the extra responses.

Use the API Latency Tester below for an initial comparison of reachable endpoints. Compare equivalent URLs and record the tool's reported timing and status. Treat it as a lightweight observation point, not a controlled concurrency generator or proof of global visitor experience.

Choose a representative workload: a static asset, a cacheable article, and an uncached application route that you own. Do not benchmark login attempts or actions that send mail. On shared infrastructure, obtain permission for load testing and respect the host's acceptable-use policy and rate limits.

Define success before testing. For example, require no unexpected errors, stable tail latency, and adequate headroom at your expected arrival rate. Avoid inventing a universal winning server; the useful outcome is whether each configuration meets your site's service target.

Make the environments genuinely comparable

Document resource limits for both environments: CPU entitlement, RAM, I/O throttling, PHP worker allowance, database placement, and concurrent connection caps. A host describing its stack as Nginx may still forward dynamic requests to Apache, so ask which component actually executes PHP.

Check software versions and cache layers. Use the same PHP build, extensions, application revision, database snapshot, compression policy, TLS configuration, and content. Warm caches consistently or explicitly test cold behavior separately. Never combine those observations into one supposedly definitive average.

The Nginx documentation describes its event-driven request handling and FastCGI integration. The Apache documentation explains multiple processing modules; Apache with the event MPM and PHP-FPM is not equivalent to prefork with embedded PHP.

Keep CDN involvement explicit. Either compare through the same CDN configuration or test authorized origins directly with the correct hostname and certificate verification. Requests served by an edge cache mostly measure that edge, not the origin server you are trying to compare.

Write down the test client's location and network path. If one origin is much farther away, transport latency can hide differences in processing time. Record that constraint rather than presenting regional differences as a web-server architecture result.

Collect a single-request baseline

Start with repeatable timing and response verification. Inspect cache headers, content length, status, and redirects before adding concurrency. A cached error page can be impressively fast while delivering nothing useful.

curl -sS -o /dev/null   -w 'status=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}
'   https://example.com/benchmark-article/
curl -sS -D /tmp/blog-headers.txt   -o /tmp/blog-body.txt https://example.com/benchmark-article/

Curl's timing fields are cumulative milestones, not independent durations. Subtract connection time from TLS completion when investigating the handshake phase. Time to first byte includes earlier network work, so it is not a direct measurement of PHP execution time.

Run several repetitions and retain individual observations. Record redirects separately rather than hiding them behind automatic following. Check the downloaded body for an expected title or marker, and ensure both environments return equivalent content and cache policy.

Use the latency testing tool again after changes for a quick consistency check. For full browser rendering, add browser measurements separately: HTML response speed does not include image decoding, JavaScript execution, or layout stability.

Increase load gradually and preserve evidence

Use a staging clone or a provider-approved test window. Begin with low concurrency, wait for stable behavior, then increase one variable at a time. ApacheBench is widely available, though its connection model is not a complete simulation of modern HTTP/2 browsers.

ab -n 100 -c 2 -k https://example.com/benchmark-article/
ab -n 300 -c 5 -k https://example.com/benchmark-article/
ab -n 100 -c 2 -k https://example.com/wp-json/

These are deliberately small starting runs, not recommended production traffic levels. Confirm that the selected endpoint exists and that your provider permits even these requests. ApacheBench reports failed requests and percentile timings; inspect them alongside server logs rather than quoting requests per second alone.

Capture tail latency, non-success statuses, and actual response sizes. Stop immediately when errors rise, resource alarms fire, or other tenants might be affected. Repeatedly pushing past a known limit provides little additional information and can breach hosting terms.

Repeat each condition in multiple rounds, alternating environment order. A shared server's noisy neighbors can change results during the same afternoon. Retain raw output and configuration notes so a later retest can distinguish a genuine improvement from ordinary variability.

Explain the bottleneck before choosing a stack

A static-file advantage does not automatically improve uncached PHP throughput. If every dynamic request waits for a database lock, changing the front-end server may leave the limiting resource untouched. Check PHP queues, slow queries, disk latency, and upstream errors together.

For accounts without system access, request provider metrics around the exact test window. Ask whether throttling, worker limits, or account-level entry-process limits were reached. An unexplained plateau is not evidence that a server product cannot scale.

If you administer the server, correlate access and error logs with resource observations. This example reads status only; available tools and service names vary by distribution.

uptime
free -m
vmstat 1 10
sudo journalctl -u nginx --since '15 minutes ago' --no-pager
sudo journalctl -u apache2 --since '15 minutes ago' --no-pager

Consult web.dev for the distinction between server responsiveness and user-facing performance. Faster HTML delivery matters, but heavy assets or render-blocking scripts may still dominate the page experience.

When queues point at PHP, continue with the PHP-FPM worker guide. Avoid increasing concurrency blindly: extra workers consume memory and can overload the database sooner.

For choosing hosting, summarize observed behavior rather than declaring a winner. A useful report lists workload, cache state, authorized load level, errors, latency distribution, and resource limits. Then evaluate operational requirements such as rewrite compatibility, support access, configuration control, and migration effort.

A site dependent on per-directory rewrite rules may value Apache compatibility more than a small static-file difference. A mostly cached publication may benefit more from correct cache invalidation than either server's synthetic benchmark score.

Key takeaways

• Compare equivalent workloads with identical application state, caching, and documented resource limits.
• Use single-request timing as a baseline, then test authorized concurrency separately.
• Track errors and tail latency, not only headline throughput or averages.
• Diagnose PHP, database, and account quotas before attributing slowdowns to Nginx or Apache.
• Choose the stack that meets measured requirements and operational constraints, not a universal benchmark ranking.