Performance
What is TTFB?
TTFB measures the time from a request being sent to the first byte of the response arriving. It combines network latency with server processing time, which is why it is dominated by distance for a fast application and by the application for a distant one.
Why TTFB matters
It combines network latency with server processing time, which is why it is dominated by distance for a fast application and by the application for a distant one. It feeds directly into Core Web Vitals.
TTFB in practice
When you are running a server, TTFB is what you see in curl, in the browser's timing tab, and in your logs after every request. A high TTFB usually means one of two things: the client is far from the instance, or the application is slow to respond. Change the architecture to move the application closer, or profile the request path to find the slow handler. Getting it wrong means users perceive every page as slow, and Core Web Vitals suffers.
What people get wrong about TTFB
A common error is treating TTFB as purely a network metric and blaming the host when it is high. TTFB includes server processing time. Before you accuse the network, check the application: a heavy query or a misconfigured proxy can inflate TTFB. Always split the measurement: run a static file test versus an application endpoint to isolate the cause.
TTFB — common questions
What is a good TTFB?
There is no single number that fits every case, because TTFB depends on distance and the application. For a fast application on the same continent, under 100 ms is typical. A slow database can push it into seconds. Measure your own baseline and track changes over time.
Why is TTFB high but page loads fast?
TTFB is only the time to the first byte of the response. The rest of the content may download quickly, so a high TTFB can be masked by subsequent parallel transfers. But the user waits for that first byte before the browser can render anything, so a high TTFB still delays perceived load.
More from performance
- CPU steal time
- Steal time is the proportion of time a virtual CPU was ready to run but the hypervisor gave the physical core to another guest.
- RTT
- RTT is the time for a packet to travel to a destination and for the response to return, measured in milliseconds.
- Jitter
- Jitter is variation in packet delay over time, as distinct from the average delay itself.