TTFB vs latency: what's the difference?
Latency is how long the network takes to carry a packet to the server and back — the round trip time (RTT). TTFB (time to first byte) is latency plus everything your server does before responding: parsing the request, querying the database, rendering. Latency is a network property; TTFB is a network and application property. That’s why you can have great latency and terrible TTFB — but never the reverse.
The anatomy of one request
A fresh HTTPS request spends time in five places, in order:
DNS lookup resolve the hostname to an IP TCP connect one round trip to open the connection ← latency TLS handshake 1-2 more round trips to negotiate crypto ← latency × 2 TTFB request sent → first response byte ← latency + server work Download first byte → last byte
Notice latency appears everywhere: a 50ms RTT costs you 50ms in TCP, ~100ms in TLS, and another 50ms inside TTFB before the server has even started thinking. This is why connection reuse (keep-alive, HTTP/2) matters so much — a warm connection skips DNS, TCP, and TLS entirely, leaving TTFB ≈ RTT + server time.
Which one to optimize
- High latency, normal server time: the fix is physical or architectural — a CDN or edge region closer to users, connection reuse, fewer round trips. Your code isn’t the problem.
- Low latency, high TTFB: the time is inside your server — slow queries, N+1 patterns, synchronous upstream calls, missing caches. The network can’t save you; profiling can.
- Both high: fix server time first — it usually dominates, and it’s the part you control from your editor.
How to separate them in practice
On localhost, latency is effectively zero, so local TTFB ≈ pure server time — the cleanest measurement of your application you can get. Measure locally first; if TTFB is 250ms on loopback, no amount of CDN will make production feel fast. Tools that split requests into the phases above (browser DevTools’ Timing tab, curl -w, or a local profiler like Lobe that captures every request’s DNS/TCP/TLS/TTFB breakdown as you use your app) make the latency-vs-server-time question a reading exercise instead of a debate.