TTFB Explained: Time to First Byte and Web Speed

Quick answer: time to first byte (TTFB) is how long you wait, from sending a request, until the first byte of the server's reply arrives. It is the sum of network latency (finding the server, opening a connection, securing it, sending the request and receiving the first piece of the answer) and the server's own processing time. A TTFB of about 800 ms or less is usually considered good for a page load, and a few hundred milliseconds or less is common for well-cached content near the user. Because TTFB is mostly a mix of round trips and server work, it is the single most useful bridge between "network latency" and "how fast does my site feel".

What is TTFB?

Time to first byte (TTFB) measures the delay before a response starts. It does not tell you how long the whole page takes to download; it tells you how long the browser sat waiting before anything came back. Everything the browser does next, parsing HTML, discovering CSS, scripts and images, depends on receiving that first part of the response, so a slow TTFB delays every later step.

Technically, in a browser the metric is measured from the start of the navigation (or request) to the moment the first byte of the response arrives (the responseStart value in the Navigation Timing API). Depending on the tool, it may include or exclude redirects, so it is worth checking the definition before comparing numbers.

What does TTFB include?

TTFB is a chain of steps. Each one must finish before the next can begin, so their times add up.

1. Redirects: if the address redirects (for example from http:// to https://, or from the bare domain to www), each hop is a fresh request with its own delay.
2. DNS lookup: the browser turns the hostname into an IP address (see DNS explained). A cached answer costs almost nothing; an uncached one costs at least one round trip to a resolver and sometimes more.
3. TCP connection: one round trip to open a connection (see TCP and UDP explained). HTTP/3 over QUIC combines connection and security setup.
4. TLS handshake: for HTTPS, one additional round trip with TLS 1.3, two with TLS 1.2, unless an earlier session can be resumed (see TLS and the HTTPS handshake).
5. Request travel: the request crosses the network to the server, half a round trip.
6. Server processing ("think time"): the server receives the request, may query a database, run application code, call other services and build the response.
7. Response travel: the first byte crosses the network back, the other half of a round trip.

Steps 5 and 7 together form one round trip. A convenient approximation, with a fresh connection, TLS 1.3 and a cached DNS answer, is:

TTFB ≈ 3 × RTT + server time

where RTT is the round-trip time to the server (one RTT each for TCP, TLS and the request/response). With an already open connection it falls to 1 × RTT + server time.

TTFB vs latency vs ping

Measurement	What it covers	Typical use
Ping (ICMP RTT)	Network round trip only, to an IP address	Quick path check
Network latency (RTT)	The delay of the path; usually the same idea as ping	Comparing locations and connections
HTTPS request timing to first byte	DNS, TCP, TLS, request and server processing	Application-level responsiveness
TTFB	The same as above, usually measured per page request	Web performance diagnostics
Full page load	All resources, rendering and scripts	User experience

The relationship is that TTFB is built on latency but is always larger. If you only look at ping, you miss the setup round trips and the server's work; see ping vs HTTPS latency for why the same server can show different numbers in different tools.

What is a good TTFB?

Since TTFB depends on distance and on how much work the server does, there is no single magic number. Commonly used guidance for page loads is:

TTFB (for most visitors)	Commonly described as
About 800 ms or less	Good
Between about 800 ms and 1,800 ms	Needs improvement
More than about 1,800 ms	Poor

These bands are usually applied to a high percentile of real-user measurements (for example the 75th percentile), not to a single test. For other kinds of request, expectations are different:

• Small static file from a CDN edge near the user: often 30 to 150 ms.
• Cached HTML page: roughly 50 to 300 ms depending on distance.
• Dynamic page with database work: 200 to 800 ms is common; more means the application needs attention.
• API call: varies widely; see latency for websites and APIs.

Why distance matters so much for TTFB

Because TTFB multiplies RTT by about three, geography matters more than people expect. Light in fibre travels about 200,000 km/s, which is roughly 1 ms of round-trip time per 100 km of fibre (see undersea cables and the speed of light). Real paths are longer than straight lines, so treat these as rough.

Visitor to server RTT	Network share of a cold TTFB (3 × RTT)	With server time of 100 ms
10 ms	30 ms	About 130 ms
40 ms	120 ms	About 220 ms
100 ms	300 ms	About 400 ms
200 ms	600 ms	About 700 ms

A visitor 200 ms away spends 600 ms on handshakes and the request before the server's 100 ms is even a significant part. Two ways to attack this are to move the content closer using a CDN, and to avoid repeated setup with connection reuse and newer protocols (see HTTP/1.1, HTTP/2, HTTP/3 and QUIC).

Worked example: breaking down a slow TTFB

A site owner sees a TTFB of 1,150 ms for visitors in a distant region. Measuring the steps with a tool that reports them separately gives:

Step	Time	Notes
Redirect from http to https	180 ms	One extra round trip to the server
DNS lookup	60 ms	Uncached, resolver far away
TCP connect	180 ms	One RTT of 180 ms
TLS handshake	180 ms	TLS 1.3, one RTT
Request and first byte	550 ms	180 ms network plus 370 ms server think time

Totalling: 180 + 60 + 180 + 180 + 550 = 1,150 ms. The server is responsible for 370 ms; the network and setup account for the other 780 ms. Fixes in order of likely benefit: serve the page from an edge location near the visitor (reducing every RTT term), enable HSTS and remove the redirect hop for returning visitors, cache the page so server think time falls from 370 ms to a few tens of milliseconds. The final TTFB could plausibly land under 300 ms, but that depends on what the edge can cache.

A second example: why the first test is slower

A browser requests a small file five times in a row from a server 50 ms away. The first request needs a new connection: roughly 50 (TCP) + 50 (TLS 1.3) + 50 (request) + 5 (server) = 155 ms. If the browser keeps the connection open, the next requests cost about 50 + 5 = 55 ms. So readings of 155, 55, 56, 54 and 57 ms are completely normal, and the average (75 ms) describes neither the first nor later requests well. Looking at the minimum, median and maximum separately is more informative (see mean, median, min and max).

How to measure TTFB

In the browser

Developer tools show timing for each request: the Network panel's "Waiting for server response" is the time spent after the request was sent until the first byte arrived. The Navigation Timing API exposes responseStart for scripts, and many real-user monitoring tools collect it from actual visitors.

From the command line

curl can print each stage with its write-out variables, for example curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://example.com/. Values are cumulative from the start, so subtract neighbouring values to get each step's duration.

With GlobeLatency

The GlobeLatency test times real HTTPS requests from your device to public servers around the world, from the start of the request until the response headers arrive. That is effectively a time-to-first-byte measurement for a small asset. Each pass uses a cache-busting query string and cache: no-store so the response is not taken from the HTTP cache, but a connection may still be reused, so later passes can be faster than the first. If you add your own server as a custom destination, a small static file such as /favicon.ico shows network-plus-light-server time, whereas a full page URL also includes your server's processing time. Comparing the two tells you roughly how much of your TTFB is the application.

Because browsers hide the HTTP status for this kind of request, a 404 still produces a timing; check that you are measuring the URL you intended.

How to improve TTFB

• Put content near users: use a CDN or multi-region hosting so RTT is low (see data centres, cloud regions and edge).
• Cache aggressively: full-page or API caching at the edge removes server think time for most requests.
• Cut redirects: link directly to the final HTTPS address and keep a single canonical hostname.
• Reuse connections: keep-alive, HTTP/2 multiplexing and HTTP/3 reduce repeated handshakes.
• Use TLS 1.3 and session resumption: fewer round trips for new and returning visitors.
• Speed up the server: profile slow queries, add indexes, use an application cache, keep the runtime and framework warm, and avoid synchronous calls to slow third-party services.
• Use a fast DNS provider with sensible TTLs: short TTLs improve flexibility but increase lookups.
• Check the user side too: a slow Wi-Fi link or heavy bufferbloat can inflate TTFB for a visitor even when your server is fast.

TTFB and the rest of web performance

TTFB is the start of the page-load timeline, followed by steps such as First Contentful Paint and Largest Contentful Paint (LCP). Google's published Core Web Vitals target for LCP is 2.5 seconds or less for most visitors. If TTFB takes 1.2 seconds, only 1.3 seconds remain for downloading, parsing and rendering the main content. A low TTFB does not guarantee a fast page, since heavy images, scripts and layout work come later, but a high TTFB makes a fast page much harder to reach.

It is also important to treat TTFB as a diagnostic, not a goal. Techniques that deliver an early first byte but then stall (for example flushing a tiny header and waiting) can produce a good TTFB and a poor experience. Always read it together with the full load timeline.

Common mistakes and myths

• "TTFB is just ping." It includes setup round trips and server work. Compare it with latency, not equate it.
• Testing from one location. A server that looks fast from the same city can be slow elsewhere. Test from the places your visitors are.
• Using one sample. TTFB fluctuates. Use many samples and look at the median and a high percentile.
• Forgetting warm and cold differences. A cached or warm connection can be several times faster than a cold one; state which you measured.
• Optimising the server when the network is the cost. If 3 × RTT is 600 ms, shaving 20 ms of PHP will not help.
• Ignoring redirects. Each redirect adds at least one full round trip and often a new connection.
• Treating a lab tool's number as what users get. Real visitors have different devices, networks and cache states.

What to do next

Run the GlobeLatency test against your own site as a custom destination, once with a small static file and once with a page URL, to see how much of the delay is network and how much is the application. Then read latency for websites and APIs for site-level targets and CDN performance testing to check that your edge network really is close to your users. For the network fundamentals underneath, what is latency is the best starting point.