CDN Performance Testing: How to Measure Edge Latency

Quick answer: to test a CDN (content delivery network), measure three things separately: the network latency from users to the nearest edge server, the time to first byte (TTFB) for a cache hit versus a cache miss, and how these differ by region. Use repeated requests from several locations, read the cache-status response headers, and compare results at similar times of day. A healthy CDN shows a short round trip to a nearby edge and a much faster response for cached files than for uncached ones.

What does a CDN do, and what should you test?

A CDN (content delivery network) is a set of servers in many cities that keep copies of your content close to users and answer requests on your behalf. How requests find a nearby server is explained in CDN and anycast. In short, a request goes to a nearby edge server. If the edge has a fresh copy (a cache hit) it replies immediately. If not (a cache miss) it fetches the file from your origin server, stores it, and replies.

That gives a CDN four properties worth testing:

• Proximity: is the edge that answers actually near the user?
• Cache effectiveness: are files being served from cache, or going to the origin every time?
• Response speed: how fast is TTFB on a hit and on a miss?
• Consistency: does it perform similarly across regions, ISPs and times of day?

What is the difference between edge latency, TTFB and total load time?

Edge latency is the round-trip time between the user and the edge server. It is mostly a function of distance and network path. TTFB is the time from starting a request to receiving the first byte of the response; it includes DNS, TCP, TLS and the server's processing (see TTFB and web performance). Total load time includes downloading the whole file or page and, for web pages, running scripts and rendering.

These layer on each other. A user 12 ms from the edge, on a cache hit, might see a TTFB of about 50 ms with a new connection. On a miss, the edge must fetch from an origin 120 ms away, so TTFB might be 50 ms plus 120 ms plus the origin's processing time. The same CDN, same user, three times the wait, because the file was not cached.

How to run a CDN test step by step

1. Pick a test object. Use a small, static, cacheable file such as a logo or a tiny script on the hostname served through the CDN. Small files isolate latency from bandwidth. Also pick one dynamic URL if you want to test uncacheable behaviour separately.
2. Check cache headers. Run curl -I https://your-site.example/logo.png twice. Look for a cache status header and an Age header that grows on hits. Header names differ by provider, so check your provider's documentation for the exact ones.
3. Measure phases. Use curl -o /dev/null -s -w with variables such as time_namelookup, time_connect, time_appconnect and time_starttransfer to separate DNS, TCP, TLS and TTFB.
4. Repeat. Run at least 10 to 20 requests per location and look at the median and a high percentile, not one reading. See percentiles.
5. Test from several places. Repeat from each region you serve.
6. Test at different times. Peak evening hours and quiet night hours can differ, especially on consumer ISPs.
7. Record both cold and warm. The first request after a purge or for a rarely requested file is a likely miss. Later ones should be hits.

How do you find which edge is serving you?

Most CDNs send a response header identifying the point of presence (PoP), often an airport-style or city code, though the header name and format are provider-specific. Combine it with the round-trip time: if the code says a city on another continent and your RTT is 150 ms, you are being served from far away. With anycast CDNs the same IP address is announced from many locations and routing decides which one you reach, so you can sometimes be sent to a farther PoP than expected because of how your ISP peers; see routing, BGP and peering.

A rough proximity check is the latency itself. The physics rule is about 1 ms of RTT per 100 km of fibre path. A 10 ms RTT to an edge means it is likely within a few hundred kilometres at most. A 90 ms RTT means it is likely thousands of kilometres away, or the path is indirect.

What does GlobeLatency show for CDN-hosted destinations?

GlobeLatency runs in your browser and times real HTTPS requests from your device to public servers worldwide, from request start to response headers. Many of its public destinations sit behind anycast CDNs, so a good result tells you that the nearest edge for you is close, which is the point of a CDN. On the live map, anycast or CDN destinations are drawn where the hostname lookup resolved, not at the company's head office, so a pin may look surprising; that is expected.

You can also add your own CDN-served hostname as a custom destination. Use a small static file such as /favicon.ico to measure network latency, or a full page URL to include server processing time. Custom destinations are kept only in your browser. The numbers include DNS, TCP and TLS when a new connection is needed, so they sit a little above raw ping; see ping vs HTTPS latency. The result tile compares you with the world average for shared destinations; for how that comparison works see global comparison explained.

An important limitation: GlobeLatency measures from your location. It tells you how the CDN performs for you, not for visitors elsewhere. To cover other regions you need measurements taken in those regions.

How to tell a cache hit from a miss by timing

When headers are unavailable, timing gives a clue. Request the same file several times and compare TTFB:

Request	Typical pattern	What it suggests
1st request	TTFB clearly higher	Cache miss, edge fetched from origin
2nd to 5th	TTFB drops and stays flat	Cache hit
Every request is slow	TTFB stays high	Not cacheable, short lifetime, or each request has a unique URL
Fast then occasionally slow	Periodic spikes	Cache entry expired and was revalidated or refetched

Note that large CDNs often have many servers per PoP, and different servers may have separate caches, so a second request can occasionally land on a server without the file. Do not read too much into a single spike; repeat the test.

What can distort CDN test results?

• Connection reuse. The first request includes DNS, TCP and TLS setup; later ones may skip them. Compare like with like.
• Cache-busting query strings. Adding a random parameter, as many measurement tools do to avoid browser caching, can make the CDN treat each request as a different object and fetch it from the origin every time, unless the CDN is configured to ignore query strings. If you test with such a URL, you may be measuring misses.
• Your own network. Wi-Fi, VPNs, corporate proxies and browser extensions change results. See accuracy and limitations.
• DNS resolver location. Some CDNs choose an edge based on where your DNS resolver is, not where you are. A distant public resolver can steer you to a distant edge.
• Time of day. Congestion varies through the day.
• Test machine in a data centre. Cloud-based test agents sit on well-connected networks and often look better than real users on residential or mobile connections.

Worked examples

Example 1: a hit is three times faster than a miss

You test a 20 KB image from a city 15 ms from the nearest edge. The origin is 110 ms from the edge. First request (miss), new connection: DNS cached, TCP 15 ms, TLS 1.3 15 ms, request 15 ms plus edge-to-origin 110 ms plus origin processing 30 ms, so about 185 ms TTFB. Second request (hit), new connection: 15 + 15 + 15 + 2 ms edge processing, about 47 ms. The hit is roughly four times faster. If every request looks like the first, the file is not being cached.

Example 2: one region is slow

Testers report these median edge RTTs and hit TTFB: Europe 12 ms and 55 ms, North America 18 ms and 65 ms, Southeast Asia 140 ms and 460 ms. The provider has no nearby PoP in Southeast Asia, or the ISP routes those users to a distant one. The 460 ms is about what you would expect from 140 ms × 3 plus processing, so the cache is fine; the path is the problem. The fix is a provider or plan with a nearer PoP, or a regional origin, not more caching.

Example 3: query strings fool the test

A test tool appends ?t=random to every request. Results show high, constant TTFB of about 300 ms. Cache headers show a miss every time because the CDN includes the query string in the cache key. Testing the same file without the random parameter gives 45 ms on hits. The CDN was fine; the test was measuring origin fetches.

How do you compare two CDNs fairly?

• Serve the same test file, same size and headers, from both.
• Test both from the same locations at the same times, alternating requests so that time-of-day effects hit both equally.
• Use enough samples (dozens per location) and compare medians and p95, not best-case values.
• Test both warm (hits) and a purge or new URL (misses).
• Include the locations your real users are in, weighted by traffic, not only places where tools are convenient.
• Remember cost, features, reliability and support also matter; latency is one criterion.

Common mistakes and myths

• Testing from one location and generalising. A CDN's quality is regional.
• Measuring misses without realising it. Unique URLs, cookies, or headers that prevent caching make every request a miss.
• Using the best reading. Judge by the median and 95th percentile.
• Expecting a CDN to fix a slow origin. Misses and dynamic content still depend on the origin.
• Assuming a low ping means the site is fast. Ping shows edge proximity only, not cache or server behaviour.
• Believing the pin on a map is the server's location. With anycast, the answering server is near whoever asks.

What to do next

Run the free latency test with your CDN-served hostname added as a custom destination to see your own edge latency, then check cache headers and repeat from other regions. For the broader picture of how page and API speed depend on round trips, read latency for websites and APIs. If the numbers are higher than expected, how to reduce latency lists the options.