Response time test

What the number includes

The test asks Tenium's check service to fetch the URL and reports the elapsed milliseconds for each region that answers. The clock starts before the name is resolved and stops when the response headers have arrived, so the figure covers DNS, the TCP connection, the TLS handshake, the wait for the server and any redirects, up to five hops. The body is not downloaded. That makes it a time-to-first-byte style figure, a little longer than the server's own processing time and shorter than the time a page needs to finish loading.

The monitor behaves differently: it keeps the clock running until the body has arrived (up to 1 MB), so the response times on your monitor chart are higher than what you see here for the same URL. Compare like with like.

Why the first request is slow

A cold request pays for several round trips before the server sees anything: one for DNS, one for TCP, one or two for TLS, and a final one for the request itself. With a 100 ms round trip, a new connection costs at least 300 ms before a single byte of the page returns, even if the application answers instantly. This is why a quick test against a distant region can look bad on a perfectly healthy server.

Physics sets a floor, too. Light in fibre covers about 200 km per millisecond, so Frankfurt to New York, around 6,200 km, cannot beat roughly 62 ms of round trip, and real routes land nearer 80 to 100 ms. If your visitors are in one region, the number that matters is the one measured from that region.

Reading the colours

Rows turn green below 500 ms and amber at or above it, and red when the request fails. Google's web performance guidance treats a time to first byte up to 800 ms as good at the 75th percentile, so 500 ms is a conservative line for a single sample. Typical pages look like this:

• 50 to 150 ms: a cached page from a CDN edge, or a static site on a nearby host.
• 200 to 500 ms: a dynamic page with an object cache, or a distant but healthy origin.
• 800 to 1,500 ms: an uncached WordPress or WooCommerce page, often a plugin or a slow database query.
• Over 2,000 ms: the host is overloaded or the application is doing something expensive on every request.

One sample is not a measurement

Run the test three times before believing it. The first call may hit a cold cache, a cold connection pool or a PHP worker that has to start. A real picture needs a distribution. Take 100 checks, 90 of them at 200 ms and 10 at 3,000 ms: the mean is 480 ms, the median is 200 ms and the 95th percentile is 3,000 ms. Only the percentile tells you that one visitor in ten has a bad time, which is why alerts based on a slow threshold work better than alerts on single samples.

Be careful with regions as well. The page lists Amsterdam and London, but the check service may answer from only one of them on a given call; rows that did not answer show n/a. Treat each row as a separate sample from that vantage point.

Tracking it over time

A monitor records the response time on every check and charts it per region, so a regression after a deploy or a plugin update is visible as a step in the line. On Free the interval is 5 min; Starter brings 1 min and Pro and Agency 30 s. Alerts when the response time stays above a limit you choose are part of Pro at $29 a month and above, described under response-time monitoring. Pick the limit from a week of data, around twice the usual value, never the median.