Clients and hosts often ask the same question after a bad Waiting (TTFB) bar: should we move from Apache to Nginx (or the reverse) for better Time to First Byte? The short answer is neither option owns TTFB. A tidy Nginx vs Apache scoreboard is the wrong artefact when the real wait sits in PHP workers, database queries, missing object cache, TLS setup, or a CDN miss. The useful answer is a measurement plan: decompose the number, compare stacks honestly, and only then spend a migration weekend.
The decision path below sits beside TTFB Is Not Only the Server (name Unattributed Navigation Overhead before you blame origin) and TTFB Won't Go Down? Server-Side Culprits Beyond the Theme (origin checklist once the attributed server phase is real). Delivery-layer context lives in Network Performance for Web Teams.
What TTFB measures when you choose a web server
Time to First Byte is the span from the start of navigation until the first byte of the final response arrives. Google’s web.dev TTFB guide treats it as a supporting metric for Core Web Vitals, not a Vital itself, and still a useful early signal when it is high. Lab tools such as PageSpeed Insights and Lighthouse show Waiting (TTFB) for a single synthetic run. Field Chrome UX Report and Search Console show how real users experienced server response over a rolling window, with lag after you change origin.
For a web-server decision, that split matters. A cold lab hit against origin can look terrible on Apache or Nginx alike if PHP has to boot workers and the page is uncached. A warm hit behind a CDN may never touch the origin process your client wants to replace. Field TTFB mixes geographies, protocols, and cache states; it will not prove “Nginx is faster” two days after a panel toggle. Keep the lab note and the field note in the same change record so nobody sells a Vital win from a single synthetic Waiting bar.
Treat TTFB as a clock you must decompose, not as a brand endorsement. Redirect, DNS, connection (TCP plus TLS), request-to-first-byte, and the residual Harry Roberts and others call Unattributed Navigation Overhead can all sit inside the same label. Swapping httpd for nginx only helps the slice that was truly origin process time under comparable cache and protocol conditions. Agencies that skip the decomposition spend the next status call arguing about hosting brands while the slide still shows the same Waiting bar.
Where Nginx vs Apache shows up in Time to First Byte
Origin web-server choice shows up most clearly when:
- The request reaches the origin (CDN miss or no CDN).
- The response is dynamic (PHP, application runtime) or large static files served without an edge cache.
- You compare cold versus warm behaviour on the same URL, same protocol (HTTP/2 or HTTP/3), and similar geography.
It shows up weakly when a reverse proxy or CDN answers from cache, when TLS terminates at the edge, or when the application spends hundreds of milliseconds in database and plugin work before the first byte leaves PHP. In those cases Nginx versus Apache is theatre: the brand on the origin box is not the bottleneck the client paid to fix.
Nginx’s event-driven model is often better at high concurrent static and proxy workloads. Apache’s module ecosystem and .htaccess overrides remain common on shared WordPress hosting. Neither fact answers “what is best for TTFB” on a specific site until you measure the attributed wait. Many production stacks also run both: Nginx as reverse proxy in front of Apache or PHP-FPM. Asking which brand is “faster” without drawing that diagram is how teams migrate the wrong layer. The ticket says “move to Nginx,” the proxy was already Nginx, and PHP-FPM never changed—so Time to First Byte stays put while everyone congratulates the cutover.
Search results for nginx vs apache performance and apache vs nginx pagespeed are full of winner lists. Useful agency tables look more like this:
| Factor | Nginx (typical) | Apache (typical) | What usually moves TTFB more |
|---|
| Concurrency model | Event-driven; strong as reverse proxy / static | Process/thread workers; mature modules | Traffic shape and proxy layout, not the logo |
| Config style | Central config; no per-directory .htaccess by default | .htaccess overrides common on shared hosts | Avoiding per-request .htaccess walks helps Apache; fixing PHP still wins more often |
| Dynamic PHP | Usually Nginx → PHP-FPM | mod_php or Apache → PHP-FPM | Worker pools, opcache, object cache, queries |
| TLS / HTTP/2-3 | Widely used as TLS terminator | Also capable; often behind a proxy | Edge termination and protocol; see HTTP/2 and HTTP/3 monitoring |
| Compression | Brotli/gzip via modules or edge | mod_brotli / mod_deflate | Correct encoding and MIME lists; see Brotli and gzip |
| Caching | Fast reverse-proxy cache patterns | mod_cache / app and plugin caches | Cache hits remove origin from the path; see Cache-Control headers |
LiteSpeed appears beside Apache and Nginx on many hosting comparison pages that mention PageSpeed. Treat it as a third commercial option clients hear about from hosts, not as proof that brand A beats brand B on your URL. The same measurement rules apply: same page, cold and warm, with and without the CDN, before you credit the server product.
Therefore: Nginx vs Apache performance for TTFB is mostly a configuration and architecture question. Event-driven proxies help under concurrency. Apache with careless .htaccess and overloaded mod_php can look worse. A well-tuned Apache → PHP-FPM stack behind a CDN can beat a misconfigured Nginx box every day of the week. When you write the retainer note, prefer “we compared cold and warm Waiting on this URL, with CDN hit rate noted” over “industry benchmarks say Nginx is faster.” The first sentence survives a client engineer’s pushback; the second rarely does.
When a CDN or reverse proxy makes the origin brand moot
If most HTML or API responses are served from an edge cache near the visitor, Time to First Byte is dominated by edge hit rate, cache keys, and geography, not by whether the origin process is Nginx or Apache. The origin brand still matters for cache misses, admin paths, personalised HTML, and purge mistakes. It is no longer the useful answer to “why is field TTFB high in region X?” when the median navigation never reached that process.
Draw the path before you sell a migration:
- Browser → CDN / reverse proxy → origin web server → application / PHP → database.
- Mark where TLS ends, where HTTP/2 or HTTP/3 is negotiated, and which layer may answer from cache.
- Only then decide whether changing the origin web server package is on the critical path.
Agencies that skip this diagram migrate origin while the CDN still bypasses cache on the HTML the client cares about. Lab Waiting improves on a direct-to-origin URL nobody uses; field TTFB barely moves. That failure mode is expensive and predictable. A useful client note names which hop answered the request in the before pack and which hop you intend to change, so the after pack can fail the same test honestly.
How to measure TTFB before migrating web servers
A workable before/after usually picks one contested URL (a template the client sells, not only the homepage) and writes the numbers down beside the change ticket.
- Decompose once. In DevTools or RUM, separate redirect, DNS, connection, request→first byte, and residual (UNO). When UNO or connection dominates, a web-server swap will not fix the slide. The UNO how-to covers that residual.
- Lab, same URL, twice. One cold run (cache-bypass or private window against origin when you must isolate), one warm run that matches production cache behaviour. Record Waiting (TTFB), protocol (
h2 / h3), and whether the response was a CDN hit.
- Field baseline. CrUX or Search Console TTFB for the origin before the change is the field floor. Expect lag; one lab screenshot is a poor victory claim.
- Protocol and geography. Compare like with like. An HTTP/3 edge hit is not evidence that Nginx beat Apache on origin PHP.
- Schedule beats a single paste. Recurring lab checks give a migrate weekend a before and after under the same tool. One-off PageSpeed Insights pastes are a weak substitute; see PageSpeed Insights vs automated monitoring.
If attributed request→first-byte is already small, stop the migration conversation. The web-server logo is not earning its place on the change ticket. If the attributed wait is still large after UNO and network phases are small, open the origin checklist next, not the brand brochure.
What to fix before you swap Nginx for Apache (or the reverse)
Before you spend a cutover window on the web-server package, the boring checks usually repay more than the brand swap. Peak-hour behaviour matters more than a midnight lab run on a quiet staging box.
- Confirm PHP version, opcache, and worker/FPM pool sizing under peak, not only at midnight.
- Confirm object cache and full-page cache behaviour for the templates that matter.
- Confirm database slow queries and cron/backup storms on the same host.
- Confirm TLS and HTTP/2-3 at the edge you actually use.
- Confirm compression and Cache-Control so text assets and HTML policy match the Brotli and Cache-Control guides.
- On Apache, reduce reliance on heavy per-directory
.htaccess where you control the vhost.
- On Nginx, confirm you are not double-proxying or stripping cache headers the CDN needs.
Most of that list lives in server-side TTFB culprits. Migrate the web server when you have a clear architectural reason (proxy layout, hosting product change, operational preference), and when you can prove TTFB with the checklist above. A comparison article that crowned a winner is not that reason. Teams that cut over on mythology spend the next retainer explaining why Waiting barely moved.
FAQ
Is Nginx always faster than Apache for TTFB?
No. Nginx often handles high concurrency and reverse-proxy roles well, but Time to First Byte on a dynamic page is usually dominated by application and cache behaviour. A misconfigured Nginx origin can lose to a tidy Apache → PHP-FPM stack behind a warm CDN.
Does Apache .htaccess always ruin TTFB?
It can add per-request overhead when every request walks directory overrides, especially on shared hosts. It is rarely the whole story next to PHP and database time. Prefer vhost config when you control the server; measure before you treat .htaccess as the only lever.
Will switching web servers fix PageSpeed Insights Waiting?
Only if Waiting was true origin process time under comparable cache and protocol conditions. If Waiting was mostly connection, redirect, UNO, or a cold uncached run you will not see in the field, the scoreboard will disappoint after the cutover.
Where does LiteSpeed fit in apache vs nginx pagespeed comparisons?
Hosts often market LiteSpeed as a third option beside Apache and Nginx. Apply the same measure-before-migrate rules. Do not treat a vendor benchmark as a substitute for your URL’s cold/warm and CDN-hit tests.
Should agencies recommend Nginx by default for Core Web Vitals?
Recommend a clear path: decompose TTFB, fix CDN and application bottlenecks, then choose the origin server your ops team can run safely. Core Web Vitals care about what users experience; they do not award points for the web-server logo in Server headers.
Put the contested URL on a schedule before you migrate
If you are the technical lead deciding whether a client should move between Nginx and Apache for TTFB, freeze the brand argument until you have a before snapshot. Decompose Waiting, note CDN hits, and keep the same URL on a recurring lab check so the cutover has evidence. Migrating on a blog-post winner list burns a deploy window and leaves the attributed wait untouched. The client still sees the same field clock a month later, only with a new Server header.
Start a Watcher trial and schedule the URL you are about to change, or run a quick performance check while you assemble the before pack. Keep UNO and server-side culprits open beside the change ticket when the next host asks which brand is “best for TTFB.”
References
Originally published on Apogee Watcher.