What latency you can actually expect, and how to measure it yourself

Hosting copy loves to throw out a single latency number as if it applied everywhere. It does not. Latency depends on where the visitor is, where the origin is, whether the response came from the CDN edge or the origin, and physics. Rather than print a number we cannot honestly stand behind, here is how to measure your own latency to the nine regions we serve and to the partnered CDN edge, and how to read the results.

Where the time actually goes

Before measuring, it helps to know what you are measuring. A single HTTPS request to a fresh connection breaks down roughly like this:

• · DNS resolution: usually cached, but a cold lookup can add 20-80ms
• · TCP handshake: one round trip, so roughly the network RTT to the nearest edge
• · TLS 1.3 handshake: one more round trip on a new connection, zero on a resumed one
• · Edge cache lookup: a HIT returns immediately; a MISS pays the trip back to origin
• · Origin processing and first byte: the part your app and database control

The honest takeaway: a cached static asset served from a near PoP can answer in a few milliseconds, while an uncached, dynamic page that has to reach a distant origin will be tens of milliseconds or more. Both are normal. The number that matters is the one you measure for your own pages from your own visitors' regions.

Measuring round-trip to the edge

Start with the network floor: the round-trip time to whatever PoP your traffic lands on. This is set by geography and routing, and no software trick beats the speed of light over the fiber between two cities. A simple curl timing breakdown shows you the layers.

# Per-phase timing for one request.
curl -s -o /dev/null -w \
  'dns: %{time_namelookup}s  connect: %{time_connect}s  tls: %{time_appconnect}s  ttfb: %{time_starttransfer}s  total: %{time_total}s\n' \
  https://your-site.example/

# Run it twice. The second run reuses DNS and often a warm
# TLS session, so it shows the steady-state number visitors feel.

Measuring from more than one place

A measurement from your own laptop only tells you about your own location. To understand what visitors across regions see, measure from several. You do not need a fancy synthetic-monitoring contract: a handful of cheap VPS instances in different regions, or any public multi-region ping and curl service, will show you the spread. Compare a cached path and an uncached path from each location so you can separate edge RTT from origin cost.

# Compare a likely-cached asset vs a likely-dynamic page
# from the same vantage point.
for url in \
  "https://your-site.example/assets/app.css" \
  "https://your-site.example/cart"; do
  echo "$url"
  curl -s -o /dev/null -w '  ttfb: %{time_starttransfer}s  x-cache below\n' "$url"
  curl -sI "$url" | grep -iE 'x-cache|cf-cache-status|age' | sed 's/^/  /'
done

Reading the numbers honestly

If a cached asset is fast from a region but a dynamic page is slow from the same region, the network is fine and the work is in your origin: a slow query, a cold cache, an external API call on the request path. If even cached assets are slow from a region, the visitor is simply far from any edge that serves them, and the fix is coverage or caching more aggressively, not a kernel tweak. Knowing which of the two you are looking at saves a lot of wasted optimization.

What we will and will not promise

We will not publish a single global p99 figure, because one number cannot be true for every page from every region, and pretending otherwise is exactly the kind of marketing we avoid. What we will do is help you measure your own latency, keep cacheable responses cached at the partnered edge near your visitors, and keep origins fast so an edge miss does not hurt. Measure it yourself, with the commands above, and trust the numbers you can reproduce.

Latency is a product of physics, routing, and your own origin. You cannot beat the speed of light, but you can measure honestly and stop optimizing the wrong layer.