Hacker News Reader

Comment by bredman | Hacker News Reader

I'm actually not sure where the data for this site is coming from (there's some mention of Pingdom on the about page) but CDN performance can vary significantly based on user location. For that reason the only CDN comparisons I really trust are ones that are taken from end-user computers of a representative sample of the viewer you're trying to optimize for.

In this case if this data is from Pingdom monitoring locations it's particularly bad for estimating performance for a JS library that's likely loaded by end-users who are not browsing the web from well connected data centers.

Agreed that the look is nice and admittedly in the absence of other data I would probably trust this data.

View on HN

Hi,

The data is based on Pingdom, yes. Recently we made sure each CDN is monitored from the same group of servers.

It's probably not ideal. It definitely would be great if we could provide some alternative metrics. Ideas are welcome. :)

In the context of full web pages how I've seen this done is by embedding a Javascript call that occurs after the page is loaded to your site. I suspect you could do something similar with this resource.

Alternatively you can look at what CDNs are hosting the resources and then just use the existing tools to compare the expected performance of each CDN. Of course this comes with a few caveats:

1/ Performance may be different on a given CDN depending on which "package" the customer has purchased. I know was the case ~1-2 years ago for Akamai.

2/ A CDN may perform well for small objects but not for larger objects, make sure you look at representative benchmarks.

3/ JS CDNs using CDN load balancing services like Cedexis mean more work to find all the CDNs that are being load balanced across (jsDelivr uses Cedexis)

(edit: formatting)

One thing that would be interesting is "Latency from where". Yandex seems to do pretty badly, but is that also true if you're in Russia?

Nice point. We've been planning a map based visualization. That would definitely help in this regard.

Why not let website visitors make your measurements by loading the JavaScript files from the CDNs in the background?

Something like (untested):

    var i = 0;
    var urls = [
      "http://cdn.jsdelivr.net/jquery/2.0.3/jquery-2.0.3.min.js",
      "http://code.jquery.com/jquery-2.0.3.min.js",
      ...
    ];

    function measureRemaining() {
        if(i >= urls.length) return;
        var url = urls[i++];
        measureLatency(url, function(latency) {
          // TODO: post (url,latency) to back-end
          measureRemaining();
        });
    }

    function measureLatency(url,responseFn) {
        var script = document.createElement("script");

        // Bust through browser cache
        script.src = url + "?bust=" + Math.random():
        
        var start = new Date().getTime();
    
        script.onload = function() {
            var end = new Date().getTime();
            var latency = end - start;
            responseFn(latency);
        };
    
        document.getElementsByTagName("head")[0].appendChild(script);
    }

    measureRemaining();

In this way, you'll get actual end-user performance from a (hopefully) large number of different network locations. You will probably want to do this in a separate iframe to avoid changing the behaviour of your webpage.

Reply on news.ycombinator.com