Server speed and TTFB: what hosting actually controls

TTFB (Time to First Byte) is the time between the moment a browser or crawler sends an HTTP request and the moment it receives the first byte of the response. It doesn't measure how long the page takes to fully finish loading, other metrics cover that, but specifically how long the server takes to start responding, which makes it the metric most directly controlled by hosting decisions, and the least influenced by what happens afterward in the browser.

The real phases between the request and the first byte

What looks like a single wait is actually a sequence of independent phases, each with its own room for optimization:

DNS resolution          0–120 ms  (0 ms if already cached by the resolver)
TCP handshake            ~1 RTT   (physical round trip to the server)
TLS negotiation         ~1–2 RTT  (less with TLS 1.3 and session resumption)
Server-side processing  variable  (routing, DB queries, HTML generation)
First byte received     = sum of everything above

DNS resolution only adds real time if the client's resolver doesn't already have the answer cached, a factor governed by the record's TTL, as explained in the DNS and technical SEO guide. Establishing the TCP connection and the TLS negotiation depend mostly on the physical distance between client and server, measured in round trips (RTT); TLS 1.3 with session resumption can cut that negotiation down to a single round trip versus the two required by earlier versions. The only phase the server controls from start to finish is processing: the actual time the application takes to decide what to respond.

What hosting controls at each phase

The type of hosting directly determines how much resource contention affects server-side processing: on shared hosting, dozens or hundreds of accounts compete for the same CPU and memory, so a traffic spike on a neighboring account can degrade a site's TTFB even though nothing changed on its own end; a VPS or a dedicated server isolate those resources, giving a much more predictable TTFB under load.

The server's physical location relative to the target audience directly affects the RTT of the connection phases: network latency is ultimately physical, bound by the speed at which the signal travels, so a server in Europe serving an audience mostly in Australia adds a fixed latency no code optimization can remove, only mitigate with a CDN or additional servers closer to that audience.

The PHP version and OPcache usage directly affect processing time: OPcache stores the already-compiled bytecode of PHP scripts in memory, avoiding re-parsing and recompiling the same file on every request; without OPcache enabled, every request pays that compilation cost again. Beyond caching, every major PHP version has brought substantial performance gains on its own: the jump from PHP 7 to PHP 8, for instance, translated in public benchmarks into several-fold improvements in execution time for typical workloads, regardless of any other tuning.

Database queries are, on applications with dynamic content, the most common cause of slow processing: missing indexes on columns that get filtered or sorted frequently, or N+1 query patterns (where a list triggers one extra query per item instead of a single aggregated query) that multiply response time far beyond what the actual data volume justifies.

Concrete benchmarks: what's good, acceptable and poor

As a practical reference, a TTFB under 200 milliseconds is considered good (Google's own documentation has historically used that figure as a server response time target); between 200 and 600 milliseconds is considered acceptable but improvable; above 600 milliseconds, PageSpeed Insights explicitly flags server response time as an issue to fix. The Chrome User Experience Report (CrUX) also tracks TTFB as an independent diagnostic metric, not one of the three Core Web Vitals itself, but a signal Google reports that helps diagnose why LCP is failing.

How TTFB relates to Core Web Vitals without repeating that guide

TTFB isn't a Core Web Vital by itself, but it acts as its floor: no content element can start painting before the HTML that contains it has started arriving, so a 1.5-second TTFB leaves, at most, one second of room to meet the "good" LCP threshold covered in the Core Web Vitals guide, no matter how fast the rest of rendering is. That's why a slow server problem doesn't get fixed by optimizing images or JavaScript: those optimizations kick in after the first byte has already arrived, never before.

What can be done at the hosting level without touching the page's code

Enabling and correctly tuning OPcache (adjusting its memory allocation and how often it revalidates modified files) is usually the cheapest improvement available. An object or query caching layer (Redis, Memcached) avoids repeating the same heavy query on every request when the result barely changes between visits. Keeping connections alive avoids repeating the TCP and TLS handshake on consecutive requests from the same client. A CDN with edge-cached content, as explained in the HTTP caching and CDN guide, can serve cacheable pages directly without the request ever reaching the origin server. And choosing a data center close to the main audience, or leaning on a CDN with anycast routing as explained in the DNS and technical SEO guide, reduces the perceived distance in practice without needing to move the origin server.

Frequently asked questions