TTFB vs response time vs latency: what each one measures

What each term means

Network latency, often reported as round-trip time, is the time a packet spends traveling to the server and back with no application work in between. It is set by physical distance, the number of hops and the quality of the route. Nothing you do in your code changes it.

Time to first byte (TTFB) is measured from the moment the client starts the request until the first byte of the response reaches it. That span contains the DNS lookup, the TCP connection, the TLS handshake, the time the request spends in flight, whatever the server does to produce an answer, and the trip back. TTFB is therefore always larger than one round trip, usually by several.

Response time is the loosest of the three. Most monitoring tools use it for the total time to complete the request, from the first packet to the last byte of the body. Some tools use it as a synonym for TTFB. Before you compare two numbers labeled "response time", check what each tool stopped the clock on.

How each one is measured

Latency comes from an ICMP echo, which is what ping sends, or from timing the TCP handshake when ICMP is blocked. TTFB and total time come from the HTTP client itself. One curl invocation prints all of the boundaries:

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/

Each value is cumulative from the start of the request, so you read them as boundaries rather than as durations. Subtract the previous one to get the length of a stage.

Which number your tool is showing you

Every tool reports a different slice of the same request, which is the usual reason two measurements of one site disagree:

• ping reports round-trip latency only, with no server work included
• curl -w reports every boundary listed above, which makes it the reference when numbers disagree
• Browser developer tools show TTFB as the waiting stage of a request, separated from the download stage below it
• Lighthouse and PageSpeed report server response time, which is TTFB for the document request
• Uptime monitors report a response time whose definition varies by product, and which includes connection setup from wherever the check ran
• Real user monitoring reports field TTFB, aggregated across real visitors on real networks

What a good number looks like

Latency is bounded by geography. Under 30 ms is normal inside one metro area, 50 to 100 ms across a continent, and 150 to 250 ms between continents. A route that measures well above the distance suggests a bad path rather than a slow server.

For TTFB, web.dev treats 800 ms or less as good and anything over 1.8 seconds as poor, while Lighthouse's server response time audit starts failing above 600 ms. Aim under 600 ms for the document request and treat 200 ms as the target for anything cached or served statically.

Total response time depends on the size of what you are sending, so there is no universal figure. Measure your own baseline on a normal day and treat the change from it as the signal, not the absolute number.

Reading the gaps

The individual numbers matter less than the distance between them, because each gap points at a different subsystem:

• TTFB minus round-trip latency is roughly how long the server spent thinking. If that is the large part, the problem is application code, a slow query or a cold cache
• Connect minus DNS lookup is one round trip for the TCP handshake. If it is much larger than your measured latency, the network path is congested or misrouted
• TLS minus connect is the handshake cost, typically one or two extra round trips, and a large value points at certificate chain or session resumption problems
• Total minus TTFB is transfer time. If that dominates, the response is too big or the connection is too slow, and no server tuning will help
• DNS lookup on its own should be a few milliseconds once cached. A consistently slow lookup is a resolver or authoritative nameserver problem, not a web server one

The same reading works in reverse when only one location is slow. Equal server think time everywhere, with the difference living entirely in latency and transfer, means the server is fine and the route is not. Run the check from several places before you touch the application.

Measuring it in one place

To see these numbers for a page without assembling them by hand, run the page speed test, which loads the page from an outside location and breaks the load into its stages. The server response time guide covers the same measurement from the command line. A single run tells you about that moment only, so if the number matters, put a scheduled check on it: HostTracker measures response time on every check from 300+ checkpoints in 158 cities, which is what turns one reading into a baseline you can spot a regression against. More definitions are in the monitoring concepts section.