Response time answers a plain question: after something asks for your website, how long until the answer arrives? A monitoring tool asks the same way a browser does, with an HTTP request, and measures the wait.
It is one of the few numbers that shows a problem before it becomes an outage. A site that answers in 300 milliseconds on Monday and 2,500 milliseconds on Friday is still "up", but something has changed.
What happens during a request
A single request passes through several stages. Each one takes time, and each can be slow for a different reason.
- DNS lookup. The name
example.comis turned into an IP address. This can be fast when the answer is cached nearby and slow when it is not. - TCP connection. The client opens a connection to that address. The time depends mostly on distance and the quality of the network path.
- TLS handshake. For
httpsaddresses, the two sides agree on encryption and the client checks the server's certificate. This adds a few more round trips. - Request and server processing. The request is sent. The server may read files, query a database, or run application code before it can reply.
- First byte. The first part of the answer arrives. The time until this moment is called time to first byte (TTFB).
- Rest of the answer. The remaining data is transferred.
Redirects add to this. If the address answers with a redirect, the client repeats the stages for the next address. A chain of redirects multiplies the cost.
Time to first byte and total time
Two numbers are used most often:
- Time to first byte (TTFB) is the wait until the first byte of the answer arrives. How far back it starts depends on the tool. The web performance guidance on web.dev counts it from the start of navigation, which includes redirects, DNS lookup, connection setup, TLS negotiation, and the wait for the server. Some tools measure only from the moment the request is sent, which excludes the setup stages. When comparing numbers from different tools, check which definition each one uses.
- Total response time is the time until the answer has been received. For a simple page check it adds the transfer of the answer to TTFB.
A high TTFB with fast connection stages points at the server or the application behind it. Slow DNS or connection stages point at the name server or the network.
Response time and latency
Latency is the delay that the network itself adds, mainly the time a signal needs to travel. Distance matters: a request from Singapore to a server in Frankfurt takes longer than one from Berlin, even if the server is equally fast. Response time includes latency plus the work done by the server.
Response time is not page load time
A monitoring check requests a single address and measures the answer. It does not behave like a browser opening a page.
A browser also downloads images, stylesheets, scripts, and fonts, runs the scripts, and draws the page. Measures of that experience, such as largest contentful paint or the Core Web Vitals, describe what a visitor sees and when. They need a real browser.
A page can have a fast server response and still feel slow because of heavy scripts or large images. The opposite is also possible. For that reason, HTTP response time is best read as a measure of the server and the path to it, not of everything a visitor experiences. UptimeWire measures the former. It does not run a browser and does not report Core Web Vitals.
Why response time changes
- Traffic. More simultaneous visitors compete for the same resources.
- Heavy work in the background. Backups, imports, or scheduled jobs can take capacity from visitors.
- Slow database queries. A query that was fast on small data may slow down as data grows.
- Caching. A cached page can be many times faster than one built on demand.
- Changes to the site. A release, a plugin, or a new third-party call can add time overnight.
- The network. Congestion and routing changes affect connection time and may vary by time of day.
- Where the check runs. Distance to the server matters, as described above.
Checking from different places
One measurement says how the site responds from one place. Services that check from several locations can show whether a slow response is global or regional. A server that answers in 200 milliseconds near its data centre and in 900 milliseconds from the other side of the world is behaving normally. A site that is slow everywhere points to the server.
When you compare numbers over time, keep the place and the interval constant. Otherwise a change in the number may come from the method and not from the site.
A worked example
A check on an https address records:
| Stage | Time |
|---|---|
| DNS lookup | 18 ms |
| Connection | 24 ms |
| TLS handshake | 41 ms |
| First byte | 312 ms |
| Total | 335 ms |
Reading from first byte counted from the start of the check, the answer began to arrive after 312 milliseconds, of which 83 milliseconds went to setup (18 + 24 + 41). The remaining 229 milliseconds is roughly the request travelling to the server, the server preparing the answer, and the first byte coming back. If the next day's check shows 1,180 ms for first byte with the setup stages unchanged, the extra time is in the server, not in DNS or the network.
What good looks like
There is no single correct value. Web.dev's guidance on TTFB, aimed at pages that visitors load in a browser, uses 0.8 seconds or less as a rough guide for "good" and more than 1.8 seconds as "poor". Treat that as orientation rather than a target for every site. An API that other systems call may need to answer far faster. A page with heavy server-side work may reasonably take longer.
The more useful comparison is the site against its own normal: what is typical, and how does today differ?
Response time in UptimeWire
UptimeWire sends an HTTP request to each website address you configure and records the time it takes, together with the result. The first byte is counted from the start of the check, so it includes the setup stages and any redirects, and the total covers the whole check.
The breakdown by stage is part of the detailed check report, available from the Starter plan. On the Free plan you see the response time of each check, without the split into stages.