How It Works

What "Response Time" Actually Means

This is not an ICMP ping. We send a real HTTPS request - the same kind your browser uses to load web pages.

The total includes all these steps. That's why the numbers are higher than a traditional ping command.

Warm-Up vs. Steady State

The first request to any endpoint includes DNS resolution, TCP connection, and TLS handshake. This is the "Setup" time. Immediately after, a second request fires using the established connection. This is the actual response time.

Both values are always shown so you can see the full picture.

CORS vs. No-CORS

We try to read the full HTTP response first (CORS mode). When this works, you see the actual status code (HTTP 200, HTTP 503, etc.).

Some servers don't allow cross-origin requests. In that case, we fall back to no-cors mode, which still measures timing but can't read the status code.

What Server Probes Add

Server probes run from our infrastructure in multiple geographic regions (US East, EU Central, Tokyo). They check curated endpoints every 15 minutes.

Server probes show you what the rest of the world sees. If your latency is high but the server probe is fine, the issue is between you and the endpoint.

Community Data

When users opt in to sharing their results, the data is anonymized and aggregated to show real-world latency distributions.

Community data requires a minimum of 5 independent reports before being displayed. Statistically outlier values are automatically rejected.

See the Privacy page for full details on what's collected and what's not.

Reading the Numbers

What counts as "fast" depends on context and distance. Here's a rough guide:

Remember: these are HTTPS request round-trips, not ICMP pings. They're typically 2–5× higher than what a ping command would show, because they include TLS overhead and actual application-layer processing.