Find out if your CDN is down, unresponsive, serving error responses or cache misses. Check from 10 locations around the globe, including US, Brazil and India. Learn more.
Learn more about the CDN Performance Checker
- How does the CDN Performance Checker work?
- Why does the tool not show speed or latency of the CDN?
- Why are the test locations not always the same?
- Why is there no data in the POP column?
- Why is there no data for 'Cache Status'?
- Why does this tool show 4xx responses and browsers get 200?
- What request headers does the tool send?
How does the CDN Performance Checker work?
CDN Planet has 10 test machines running in datacenters around the globe, in US (3), Brazil, France, United Kingdom, Hong Kong, India, Japan and Australia. Our API sends a request to each of these 'nodes' and the nodes try to fetch the URL within 5 seconds. The fetch results (status code and response headers) are then aggregated and parsed by the API.
The nodes have dual stack connectivity (IPv4 and IPv6), use HTTP/1.1 only and follow redirects. To prevent abuse, the nodes terminate the connection to the remote IP (CDN) after receiving the response headers.
Why does the tool not show anything about CDN speed or latency?
CDNs optimize their network to deliver content reliabily and with low latency to 'real users': people who use the Internet at home, at work and on the go. The CDN Performance Checker tool however sends requests to the CDN from machines in datacenters. These datacenters may have an unoptimized network path to or from the CDN with high latency and/or high packet loss, or the CDN servers are in the datacenter as ours resulting in ultra low latency.
In short: measuring CDN response time from a datacenter is not very meaningful because it's not representative for the delivery speed 'real users' get.
Why are the test locations not always the same?
The CDN Performance Checker uses nodes that run on the Fly network. The nodes are in fixed locations, but every now and then location gets overwhelmed with traffic and then Fly routes traffic to a nearby location.
Why is there no data in the POP column?
Not all CDNs put a POP identifier in the response headers. Currently, CDN Performance Checker finds the POP id for Amazon CloudFront, Bunny CDN, CacheFly, CDN77, CDNetworks, Cloudflare, Fastly, KeyCDN, Medianova, OVHcloud, StackPath and Edgio.
Why is there no data for 'Cache Status'?
The following CDNs send a response header that includes the cache status: Amazon CloudFront, Azure CDN (Micrososft), Bunny CDN, CDN77, CDNetworks, Cloudflare, Fastly, Gcore, ImageEngine, KeyCDN, Kingsoft Cloud, Medianova, OVHcloud, StackPath and Edgio.
If the tested URL does not point to one of those CDNs, the CDN Performance Checker can't show Cache Status.
Why does this tool show 4xx responses and browsers get 200?
We've tried to find a set of request headers that makes it look like the request comes from a modern browser, but a CDN may still reject the request because it's from a network that seems 'bad'. For example, Akamai returns 403 to our nodes for some of their customers.
What request headers does the tool send?
The nodes send the following request headers:
accept-encoding: gzip, deflate, br
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36