What's a good website response time to aim for?

For a straightforward page, a p95 time to first byte under a few hundred milliseconds is a reasonable goal, but the target that matters is your own measured baseline. Record your normal p50, p95, and p99 first, then treat sustained increases over those numbers as the signal, not an arbitrary threshold.

Why use percentiles instead of average response time?

Averages hide slow requests. A few very slow responses barely move the mean but badly hurt real users. The p95 and p99 show what your slower and worst requests actually look like, which is where users notice pain, so percentiles give you a baseline that reflects experience rather than masking it.

How do I know if a slowdown is my server or the network?

Break the request into phases. If TTFB (time_starttransfer minus the TLS handshake) grew, it's your application or backend. If TCP connect or DNS grew, it's the network or resolver. Checking from multiple locations helps too: a slowdown seen everywhere points at your server, one region points at the path.

How to Monitor Website Response Time and Set a Latency Baseline

VigilDog Team · September 7, 2026 · 6 min read

"The site feels slow" is a hard complaint to act on without numbers. Effective website response time monitoring turns that vague feeling into a measured baseline you can defend, alert against, and improve. This how-to breaks response time into the phases that actually matter, shows you how to measure each with tools you already have, and explains how to set a baseline that catches real regressions instead of normal noise.

Break response time into phases, not one number

A single "response time" figure hides where the time actually goes. A request to an HTTPS site passes through distinct stages, and a slowdown in any one of them looks identical from the outside until you separate them. Measuring the phases tells you whether to look at DNS, the network, TLS, or your application.

The phases worth tracking are: DNS resolution (turning the hostname into an IP), TCP connect (establishing the socket), TLS handshake (negotiating the secure channel), and time to first byte (TTFB, how long the server takes to start responding after the request is sent). Total time is just the sum, useful as a headline, useless for diagnosis on its own.

DNS lookup: slow or flaky resolvers, or a misconfigured record.
TCP connect: network latency and distance to the server.
TLS handshake: certificate and cipher negotiation overhead.
TTFB: your application, database, and backend, usually the biggest lever.

Measure the phases with curl

You don't need a paid tool to see this breakdown, curl exposes every phase through its write-out timers. This one command prints each stage in seconds:

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

Each timer is cumulative from the start of the request, so the TLS handshake cost is time_appconnect minus time_connect, and the server's own thinking time is time_starttransfer minus time_appconnect. Run it a handful of times, response times vary, and a single sample tells you almost nothing. If DNS is your suspect, our DNS checker confirms whether the records themselves resolve cleanly and quickly.

Set a baseline with percentiles, not averages

A baseline is the range of normal, so you can tell abnormal apart from it. The instinct is to use an average, but averages lie about web performance: a handful of slow requests barely move the mean while ruining the experience for real users. Use percentiles instead.

Collect samples over a representative period, at least a full day, ideally a week, so you capture daily traffic peaks, and record three numbers. The p50 (median) is your typical experience, the p95 is what your slower requests look like, and the p99 exposes the worst tail. A healthy target for a simple page is often a p95 TTFB under a few hundred milliseconds, but the exact figure matters less than measuring your own numbers before anything breaks. That recorded p95 is your baseline; everything after is measured against it.

Alert on deviation from baseline, not fixed guesses

Once you have a baseline, alerting becomes principled instead of arbitrary. Rather than picking a round number like "alert if response time exceeds 2 seconds," alert when the live p95 rises meaningfully above your established baseline, say, a sustained 50% increase over several checks. That catches genuine regressions early while ignoring the single slow sample that means nothing.

Two rules keep alerts trustworthy. Require a slowdown to persist across multiple consecutive checks before firing, one slow probe is noise, five in a row is a trend. And check from more than one location if your audience is spread out; a slowdown seen from every region points at your server, while one seen from a single region points at the network path. Alert fatigue kills monitoring faster than any outage, so tune for signal.

From a script to something that watches for you

A curl one-liner is perfect for investigating a report right now. Turning it into ongoing monitoring means running it on a schedule, from outside your own network, storing the history so a baseline exists, and routing alerts somewhere you'll see them. You can absolutely build that with cron, a small database, and a notifier, and for a single site that's a reasonable weekend project.

The reason people reach for a service is that response time rarely lives alone. The same probe that measures TTFB is the natural place to also watch certificate expiry, DNS drift, and uptime, the failures that most often masquerade as "the site is slow." If you'd rather not maintain the plumbing, VigilDog's monitoring runs these checks continuously and keeps the history that makes a baseline possible. It also pairs naturally with the distinction in SSL monitoring vs uptime monitoring.