What is website response time?

What makes up response time

Several components combine to deliver content to your browser:

1. 1

   DNS lookup time

   The time to translate the domain name (e.g. example.com) into an IP address.

2. 2

   Connection time

   The time to establish a TCP connection with the server.

3. 3

   SSL/TLS handshake

   For HTTPS sites, the time to negotiate an encrypted connection.

4. 4

   Time to first byte (TTFB)

   The time from sending the request until the first byte of the response arrives.

5. 5

   Content download time

   The time to download the complete response from the server.

Response-time benchmarks

Here's what different response times mean for performance:

How we score it

TheSiteStatus records average response time across multiple windows and converts it into points that feed each site's reliability score. Faster is better — see the exact scale on our methodology page.

Response time is not the same as load time

These two get mixed up constantly, and the difference matters. Response time is how long the server takes to start answering a request — the work happening on their side before anything reaches you. Load time is how long the whole page takes to become usable in your browser, including images, scripts, fonts and everything else that has to download and render after that first response.

A site can have a quick response time and still feel slow because the page itself is heavy. But the reverse is the telling one: if the server is slow to respond, nothing downstream can save the experience. That first byte is the foundation everything else is built on, which is why we track it specifically rather than lumping it in with page weight you can't see from the outside.

What "fast" actually depends on

There's no single number that's universally good, because response time is shaped by things that have nothing to do with how well a site is run. Physical distance is the big one — a request from London to a server in Sydney carries an unavoidable round-trip cost no amount of optimisation can erase. Caching and CDNs flatten that for static content but do nothing for a request that has to reach the origin and run real logic.

Time of day plays a part too. A service that answers in 200 ms at 3 a.m. can crawl during peak hours when its servers are under load. This is exactly why we measure repeatedly over time instead of trusting a one-off reading — a single fast or slow sample tells you almost nothing.

Why the average hides the pain

An average response time can look perfectly healthy while a meaningful slice of requests are miserable. If most responses land at 300 ms but one in twenty takes four seconds, the average barely moves — yet those slow requests are the ones people remember and complain about. The worst experiences live in the tail, not the middle. A steady average paired with a worsening incident history usually means the typical request is fine but the bad days are getting worse, and that's a pattern worth watching.

What slow response time usually signals

• An overloaded server or database that can't keep up with current traffic.
• Inefficient back-end code or slow queries that add up under real load.
• Network or routing problems between the visitor and the origin server.
• A service quietly creeping toward an outage — rising response times often arrive before a site falls over completely.