How to check server response time

Response time, TTFB and page load are not the same number

They get used interchangeably and they answer different questions:

• Connection time is DNS resolution plus the TCP handshake plus the TLS handshake. It is mostly distance and network quality, and the server's own code has nothing to do with it.
• Time to first byte (TTFB) is the moment the first byte of the response arrives, measured from the start of the request. It includes connection time plus the server's processing: routing, database queries, template rendering, any upstream API calls.
• Server processing time is TTFB minus connection time. This is the part you can fix in your application.
• Page load time is everything: the HTML, then every image, stylesheet, script and font the browser fetches, plus the work of rendering them. A page can have an excellent TTFB and still take eight seconds to load.

Confusing them sends people optimizing the wrong thing. Compressing images does nothing for a slow database query, and a faster database does nothing for a page carrying four megabytes of JavaScript.

Measuring it with curl

curl reports each phase separately, which lets you split connection cost from server cost in one command:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

All values are seconds from the start of the request, so each one includes the ones before it. Server processing is ttfb minus tls, or minus connect on plain HTTP. Run it three or four times: the first request may pay for a cold cache or a fresh connection, and one sample is not a measurement.

Two things to keep straight. This measures the HTML document only, not the page, so it will always look faster than a browser test. And an uncached, logged-in or search page is often dramatically slower than the homepage, so measure the URL you care about rather than /.

What counts as normal

There is no universal threshold. These bands are a reasonable working guide for a document request measured from a location near your visitors:

• Under 200 ms. Fast. Typical of static content, a warm cache, or a CDN edge answering directly.
• 200 to 500 ms. Normal for a dynamic page that queries a database. Nobody notices this.
• 500 ms to 1 s. Noticeable. Usually a query that needs an index, an uncached template, or a slow upstream call.
• 1 to 3 s. Users feel it, and search engines measure it. Worth treating as a defect.
• Over 3 s. Something is wrong: a saturated server, a lock, an upstream service timing out, or a request doing far more work than it should.

The far more useful comparison is against yourself. A page that answered in 300 ms last month and answers in 900 ms today has a specific cause introduced in between, and knowing that is worth more than any published benchmark.

Why it varies by location

Distance costs time and cannot be optimized away. Every round trip between client and server takes at least as long as the physical path allows, and a TLS connection needs several round trips before the first byte of the response can even start. That is why the same server can answer in 150 ms locally and 700 ms from another continent while doing exactly the same work.

Routing matters too, and it is less predictable than distance: traffic between two networks can take a poor path that adds latency for one region and nobody else. If you use a CDN, some locations are served from a nearby cached copy while others miss the cache and pay the full trip to the origin, which produces a wide spread across locations for the same URL.

So measure from where your users are, not from where your server is, and compare like with like. A number without a location attached is not comparable to anything.

When slow means broken

Some slowness is a warning rather than a performance issue:

• A response time that grows steadily under load means the server is saturated. It ends in timeouts, not just slow pages.
• Times clustered at exactly 30 or 60 seconds are timeouts, not slowness. Something upstream is not answering and a proxy is waiting out its limit before giving up with a 504.
• Fast most of the time with occasional huge spikes usually points at a lock, a cron job, a backup, or a cache expiring and every request rebuilding it at once.
• Slow only for logged-in users means the cache is carrying the anonymous traffic and hiding a genuinely slow application underneath.
• Slow from one region only is a network or CDN problem, not an application problem, and no amount of backend work will fix it.

Noticing the day it changed

A single measurement tells you what happened for one request, from one place, at one moment, and response time is exactly the kind of metric that drifts rather than breaks. Scheduled checks measure the same URL from the same locations continuously, keep the history so you can point at the day it changed, and alert when the time crosses a threshold instead of when a customer complains. HostTracker runs those checks from 300+ checkpoints in 158 cities, so a regional slowdown is visible as one. Run a check now with the HTTP check tool. When the server is fast and the page still is not, the rest of the answer is in how to check website speed.