How to Reduce Time to First Byte When Your Host Is Slow
To reduce time to first byte, you have to find out where the delay is created before you change anything. TTFB is the gap between the request leaving the client and the first byte of the response body arriving, and it is the sum of several separate waits, only one of which is usually your host. Measure the parts, then fix the part that is actually slow.
What TTFB actually measures
The number your browser reports is not a single server-side figure. It bundles DNS resolution, TCP connect, TLS handshake, the time until the server starts sending, and the network transit for that first packet. A hosting provider can only own the server-side slice. If you blame the host for a slow handshake caused by a bloated TLS configuration or a distant CDN edge, you will spend money and change nothing.
Look at the Server-Timing response header if your stack emits it. It lets the application report its own internal phases, and browsers show them in the network panel. If your framework can send it, switch it on before you tune anything.
Measure TTFB before you change anything
Start with a single request and read the timing breakdown. curl gives you the phases separately, which is more useful than one blended number.
curl -sS -o /dev/null -w \
"dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" \
https://example.com/Read it left to right. A large time_namelookup means DNS. A large gap between time_connect and time_appconnect means the TLS handshake. A large gap between time_appconnect and time_starttransfer is the server thinking, and that is the part your host and your application control. If time_starttransfer is close to time_appconnect but time_total is much larger, the delay is in the body transfer, not TTFB.
Repeat the request several times and from more than one network. The first request pays connection setup; later ones reuse it. A single cold measurement will mislead you. Then compare against a static file on the same host. If a plain text file returns quickly and a dynamic page does not, the host and network are fine and your application is the problem.
Separating host, network and application
The decisive test is to remove the application from the path. Request a small static asset served directly by the web server, then request your dynamic endpoint. The difference between the two is application time. If even the static file is slow, keep going: test from a machine in the same datacenter region, then from far away. Slow only from far away points at network path or edge configuration. Slow from everywhere points at the host or the server process itself.
On the server, check whether the process is starved. High load average relative to CPU count, heavy swap use, or a saturated disk queue all push TTFB up regardless of how clean your code is. Watch a slow request while it happens rather than after the fact.
curl -sS -o /dev/null -w "%{time_starttransfer}\n" http://127.0.0.1:8080/health
uptime
vmstat 1 5Requesting the local address removes the network entirely. If time_starttransfer against 127.0.0.1 is already slow, no CDN or edge will save you, and the fix belongs in the application or the server configuration.
Practical fixes that actually move the number
Application and database
Most slow TTFB on dynamic pages is waiting on the database or on an outbound call made before the first byte can be written. Look for queries run in a loop, missing indexes, and synchronous calls to external services on the critical path. If your framework buffers the whole response before flushing, disable that for streamed pages so the first byte leaves as soon as the layout is ready. Caching rendered fragments, or a full page cache in front of the application, removes the work entirely for repeat requests.
PHP-FPM and similar process managers
If requests queue waiting for a worker, TTFB climbs under concurrency even though each request is fast in isolation. Check the pool's pm.max_children against available memory and watch the listen queue. A full queue means requests sit idle before your code even runs.
; php-fpm pool
pm = dynamic
pm.max_children = 24
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
request_terminate_timeout = 30sSize pm.max_children from measured per-process memory, not guesswork. Too few workers and requests queue; too many and the machine swaps, which is worse.
OPcache and bytecode
With OPcache disabled or its memory exhausted, every request recompiles your code before it can respond. Confirm it is enabled and that opcache.max_accelerated_files is large enough for your codebase. A cache that fills up and thrashes shows as erratic TTFB that spikes on some requests and not others.
Keep-alive and TLS
If time_connect and time_appconnect dominate, the connection setup is the cost. Enable HTTP keep-alive at the server and proxy so repeat requests reuse connections, and confirm the Connection header is not being stripped by an intermediary. For TLS, session resumption and OCSP stapling cut handshake time, and enabling HTTP/2 or HTTP/3 reduces the number of round trips a client needs. These changes help perceived speed even when the server's own processing is unchanged.
Compression and buffering
Compression reduces transfer size but can delay the first byte if the server buffers output to compress it. For small responses the effect is minor; for streamed responses it can hold back the first flush. Check whether a proxy in front of your server is buffering the response, because a buffering proxy turns a fast origin into a slow TTFB at the client.
What to do next
Run the curl timing breakdown against your real endpoint, against a static file on the same host, and against 127.0.0.1 on the server. Write the three numbers down. Whichever gap is largest tells you whether to chase DNS and TLS, the network path, or the application, and only then should you consider whether the host itself needs to change. Fix the measured bottleneck first, because moving hosts to solve a database problem just relocates the problem.
