Website Response Time Explained: Latency, TTFB, and Jitter

Click a link, and there is a small pause before anything appears. Most of the time it's short enough to ignore. Sometimes it drags, and the page feels broken before the first pixel even loads. That pause has a name and a number behind it: response time, the round trip between your request leaving and the server's answer arriving.

Response time is one of the most confused metrics in networking, partly because several different things wear the same label. A game player calls it "ping," a web developer calls it "time to first byte," a network engineer calls it "round-trip latency," and a monitoring dashboard rolls all of it into a single millisecond figure. They're related but not identical. This guide untangles them, explains what a healthy number looks like, and shows how to read a measurement when a site feels slow.

What response time actually measures#

At its simplest, response time is how long a server takes to answer a request, measured from your end. You send a small message asking "are you there?" or "give me this page," a clock starts, and it stops the moment the first reply comes back. That elapsed time — almost always reported in milliseconds (ms) — is the response time.

The number bundles together everything that happens along the way: the time for your request to physically travel to the server, the time the server spends deciding what to send, and the time for the reply to travel back. Because it captures the full loop out and back, engineers call this round-trip time (RTT). A one-way trip of 30 ms shows up as roughly 60 ms of measured response time.

There's an important distinction hiding here. Response time is not the same as how long a full page takes to load. A modern web page pulls in dozens of images, scripts, and fonts, and the total load time depends on all of them plus how fast your browser renders. Response time isolates one narrower thing: how quickly the server starts answering. That makes it a cleaner signal of whether a problem lives in the network and the server, or somewhere in the page itself.

Latency, and what it's made of#

The travel portion of response time is latency — the delay a packet experiences crossing the network. Latency is not one thing; it's the sum of four separate delays, and knowing them helps explain why some numbers are stubborn and others are easy to fix.

• Propagation delay. The time for a signal to physically cross the distance, capped by the speed of light in fibre (about two-thirds of light speed in a vacuum). This is the floor you can never beat: a request from New York to Sydney has thousands of kilometres to cross, and no amount of money buys a faster photon.
• Transmission delay. The time to push the bits onto the wire, which depends on the size of the data and the bandwidth of the link. Small requests transmit almost instantly; large ones take longer.
• Processing delay. The time routers and switches spend reading each packet's header and deciding where to forward it. Small per hop, but it adds up across a long path.
• Queuing delay. The time a packet waits in line at a busy router or an overloaded server. This is the delay that spikes under congestion, and the one most likely to make a normally-fast site feel sluggish at peak hours.

Propagation delay is why distance dominates. If you want to know whose network sits between you and a slow server, a traceroute reading shows the hop-by-hop path and where the latency actually accumulates.

Ping vs an HTTP probe#

The classic way to measure round-trip time is ping, which sends an ICMP echo request — a tiny "are you alive?" packet — and times the echo that comes back. ICMP is lightweight and answers a pure network question: how far, in time, is this host?

The catch is that ICMP is not the web. Many servers and firewalls deprioritise or silently drop ICMP, so a ping can look terrible (or fail entirely) for a host whose actual web service is perfectly fast. Worse, browsers can't send ICMP at all, so a pure ping tells you little about the experience of loading an https:// page.

That's why our Response Time checker measures with an HTTP HEAD request instead. A HEAD request asks the server for a page's headers without the body — the same handshake and routing a real page load uses, minus the payload. It travels over the actual web port the site serves on (port 443 for HTTPS), passes through the same load balancers and application layer, and returns a time that reflects what a browser would experience. It's a more honest number for "how responsive is this website" than an ICMP ping, even if it's slightly slower because it exercises the full web stack.

Ping measures the road. An HTTP probe measures the road plus the front door.

Reading the numbers: min, max, median, jitter#

A single measurement is noise. Networks vary from moment to moment, so any useful response-time tool sends several probes and reports a spread. Here's how to read each figure.

• Minimum. The fastest probe — your best-case latency when nothing is in the way. This is close to the raw physical floor set by distance.
• Maximum. The slowest probe. A high max against a low min points to intermittent congestion or an occasional slow hop.
• Average (mean). The arithmetic average of all probes. Useful, but a single very slow probe can drag it upward and mislead you.
• Median. The middle value. Often more representative than the average, because it ignores a lone outlier. When median and average diverge a lot, you're looking at an unstable connection.
• Jitter. How much the response time varies between probes. Low jitter means steady, predictable latency; high jitter means the number bounces around. For streaming, gaming, and voice calls, jitter matters more than raw latency — a steady 80 ms beats a twitchy 40 ms that spikes to 200.
• Packet loss. The percentage of probes that got no answer at all. Even a few percent of loss forces retransmissions and can make a low-latency link feel broken.

Read together, these tell a story. Low min, low jitter, zero loss is a healthy path. A low min with high jitter and occasional loss is a congested or unreliable one, even if the average looks acceptable.

What counts as a good response time?#

There's no universal pass mark, because distance sets the floor. But rough guidance holds for a server on the same continent as you:

• Under 100 ms — feels instant. Good for a nearby or well-served site.
• 100–300 ms — normal for a server on another continent, or one behind a few extra hops. Noticeable but fine for browsing.
• 300–1000 ms — sluggish. Something is adding delay: distance, an overloaded server, or a congested path.
• Over 1000 ms, or timeouts — a real problem. The server is struggling, unreachable, or dropping your probes.

Always judge a number against distance. A 250 ms response to a server on the other side of the planet is excellent; the same 250 ms to a host in your own city means something is wrong.

Why a site is slow#

When response time is worse than distance alone can explain, the extra delay usually comes from one of these:

• Server load. An overwhelmed or under-provisioned server queues requests, and queuing delay balloons. This shows up as a high, jittery number that gets worse at peak traffic.
• DNS resolution. Before your browser can connect, it has to turn the hostname into an IP address. A slow or distant resolver adds delay to the very first request. You can measure name resolution separately with a DNS records lookup.
• The TLS handshake. Setting up an encrypted HTTPS connection takes an extra round trip or two before any data flows. Over a long-distance link, that handshake alone can add hundreds of milliseconds to the first connection.
• Routing. Traffic doesn't always take the shortest geographic path. A request from one city to a neighbouring one can detour hundreds of kilometres through a distant exchange point, quietly inflating latency.
• No CDN. If a site serves every visitor from a single origin server in one country, everyone far away pays the full distance penalty. A content delivery network fixes this by caching content at edge locations close to users — which is why a well-configured global site can answer in under 50 ms almost anywhere.

Narrowing down a slow response#

When a site is slow, the goal is to figure out which of those layers is to blame. A quick sequence:

Start by measuring the response time itself, several times, from a neutral vantage point. A steady, high number that matches the distance is just physics — nothing to fix. A number that's high and jittery, or that varies wildly between refreshes, points to congestion or an overloaded server rather than distance.

Next, separate the network from the server. If the raw round trip is fine but the full page still crawls, the delay is in the application or the page assets, not the wire. If the round trip itself is slow, the problem is in the path or the server's front door. A traceroute then shows exactly which hop introduces the jump — your own ISP, a transit provider in the middle, or the destination network.

Finally, rule out DNS. If the very first request to a site is slow but subsequent ones are fast, a sluggish resolver is a likely culprit, and switching to a faster public resolver often clears it up.

Response time is a small number that quietly reflects a lot: the speed of light, the load on a machine you'll never see, and the quality of every network between you and it. Once you know what the figure is made of, a slow site stops being a mystery and becomes a diagnosis.