/tutorials/how-website-speed-is-actually-measured
How Website Speed Is Actually Measured
What DNS lookup time, connection time, TLS negotiation and time to first byte each mean, and why total load time is made of several separate delays, not one.
6 min read
Run Website Speed TestPage speed is several delays, not one
When a page feels slow, it is tempting to think of speed as a single number, but a request to a server actually passes through several distinct stages before any content arrives at all, and each one can be the culprit independently of the others. A site can have a fast server and still feel slow because of a slow DNS resolver, or a fast network path and still feel slow because the server itself takes a long time to build the response.
The stages a request actually goes through
- DNS lookup: translating the domain name into an IP address, the very first step, before any connection exists.
- Connection time: the network round trip needed to open a TCP connection to that address.
- TLS negotiation: for HTTPS sites, the additional handshake that agrees on encryption before any real data is exchanged.
- Time to first byte (TTFB): the delay between the request being sent and the first byte of the response coming back, which reflects how long the server itself took to start responding.
- Total response time: everything above plus the time to transfer the full response body.
Why time to first byte points at the server, not the network
Of all these stages, time to first byte is usually the most revealing, because it isolates how long the server itself spent working before it had anything to send back. A slow database query, an expensive template render, or an overloaded backend all show up as a slow TTFB, even if the DNS and connection stages were both fast. A fast TTFB with a slow total response time, on the other hand, usually points at a large response body rather than a slow server.
The protocol version matters too
HTTP/1.1, HTTP/2 and HTTP/3 differ in how efficiently they can handle multiple requests over one connection. HTTP/2 in particular allows a browser to request many resources over a single connection at once rather than opening a new one for each, which matters far more on a page with many small assets than on one with a handful of large ones. A server that has not enabled HTTP/2 is not necessarily broken, but is leaving a real performance improvement unused.
Trying it yourself
The Speed Test breaks a single request down into exactly these stages, so a slow result can be traced to a specific cause rather than treated as one unexplained number. Run it against a page you know well and compare the DNS, connection and TTFB figures against a page on a different host, and use the HTTP/2 Support Checker alongside it to see whether protocol version is part of the picture.
Related tutorials
