CDN for JavaScript libraries | Hacker News Reader

CDN for JavaScript libraries

cdnjs.com

99 pointsthefox29 comments

Hey guys,

Thomas from cdnjs here, we have been on HN before.

https://news.ycombinator.com/item?id=4412044 - 671 days ago https://news.ycombinator.com/item?id=2828516 - 1057 days ago

cdnjs has been very successful since inception in early 2011, this is mainly due to Cloudflare's early and ongoing sponsorship of the project.

According to BuiltWith, we have over 187,000 websites using cdnjs in production - http://trends.builtwith.com/cdn/CDN-JS

According to w3techs, we have just recently overtook Microsoft's cdn, which puts us in around third place for market size - http://w3techs.com/technologies/comparison/cd-cdnjs,cd-micro...

jsbin, codepen and jsfiddle users generally use our tool for code snippets.

We have had no major downtime and only one brief security problem which was due to a library version which had insecure swf's.

We have 100's of developers contributing to the project, and our repository has become quite active - http://www.ohloh.net/p/cdnjs

As always our thanks goes out to the community who help us keep the libraries up to date and Cloudflare's dedication to speeding up the web. A special mention goes to Pete Cooper who has been the primary moderator and sole reason for our growth in the last 12 months - https://github.com/petecooper

I will try to answer other questions in the thread today.

Edit: With regards to peoples privacy enquiries, because Cloudflare is our official mirror it is best to consult their privacy policy. I have been working with http://taskforce.is over the last year on campaigns against mass surveillance so I do take the issue very seriously.

Edit: Also a lot of users don't use cdnjs in production, it's just very convenient when developing to be able to quickly include scripts.

Atom Plugin - https://atom.io/packages/cdnjs Sublime Plugin - https://github.com/dafrancis/Sublime-Text--cdnjs

My first taught was will this be the new source of dead links on the internet like url shorteners.

Then again we're developers and we can put some libraries on the server as well in case the service dies so as long as we don't rely on them exclusively it's all good.

You did have some rather long downtime when you ran with a revoked SSL certificate.

I see no privacy policy so you have to assume that they will log all they can about your visitors.

In these global dragnet surveillance ridden times it should be a no-brainer but please don't expose your visitors to third-party websites, respect their privacy, host your assets yourself.

Agreed, especially a third party provide of javascript! It would be absolutely trivial for them to inject highly invasive tracking code into your site, or worse.

I'm not saying they will, but really it doesn't make sense to take the risk.

> In these global dragnet surveillance ridden times it should be a no-brainer but please don't expose your visitors to third-party websites, respect their privacy, host your assets yourself.

I still wish there was a "hash" attribute to script tags (and others) so that browsers could cache common JS/CSS/etc assets cross-domain.

I've been wanting this for a while now. The common argument against this is that this enables cache poisoning attacks where an attacker can craft malicious files with matching hashes. But I think the security it offers against CDNs turning rogue makes it worthwhile. Here's the draft proposal https://github.com/pwnall/script-digest

If the hash was SHA-512 wouldn't that be hard?

Ugh. This proposal also suggests using "magic comments" in scripts, which needs to die. They will get stripped by things like pagespeed and various acceleration proxies, completely outside the developers control.

shouldn't it be something like <script src="blah" data-hash-sha512="...">?

I think the assets are served via cookie less connection.

    prasanth:~/ $ http get http://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.1/jquery.min.js                                           [18:22:12]
    HTTP/1.1 200 OK
    Access-Control-Allow-Origin: *
    CF-Cache-Status: HIT
    CF-RAY: 13f0d5579cd70bab-HKG
    Cache-Control: public, max-age=30672000
    Connection: keep-alive
    Content-Encoding: gzip
    Content-Type: application/javascript
    Date: Mon, 23 Jun 2014 12:54:17 GMT
    Expires: Sat, 13 Jun 2015 12:54:17 GMT
    Last-Modified: Thu, 01 May 2014 17:45:11 GMT
    Server: cloudflare-nginx
    Transfer-Encoding: chunked
    Vary: Accept-Encoding

Edit: found this other thread[1] where the above is not true for cloudflare customers.

[1] - https://news.ycombinator.com/item?id=4912134

CloudFlare WWW developer here: since that thread we fixed our GA inserts on our web properties and turned off the usual CDN cookies for CDNJS.

Well, this also allows powerful actors to inject malicious code into your page. I think they can easily be forced via an NSL to target certain websites or client IPs.

This a thousand times.

I'm not accusing these guys of being dishonest, but we know that the three-letter organizations do this sort of thing, both with and without the knowledge of web hosts.

It seems like these guys (and anyone else who has a similar service) shouldn't require people to trust them. Instead, they should allow CORS (it appears cdnjs does) and provide boilerplate code that verifies the script's sha256 before inserting it into the page.

So now the big question is... any reason to switch to this from googleapis.com? Short term loss in cacheablilty since the Google one is so widespread, long term less dependence on the Google corporation. Insecurity since CloudFlare seems like a prime target for an acquisition/acquihire.

It's not a representative test (as I'm only providing one source), but I'm seeing lots and lots of websites proving that CloudFlare is faster than Google's CDN.

It might be because their "userbase" is still smaller than Google, but for now that might be 1 interesting reason to use CloudFlare.

http://www.baldnerd.com/make-your-site-faster-cloudflares-cd...

No clue about their relative speeds, but that test is pretty bad, as it seems to only measure transfer rate once the transfer starts, not total transfer time (including latency).

I just picked the first result from Google. This isn't StackOverflow, so I could imagine that the topicstarter would actually do some research himself.

I am in Brazil and I have a 15ms RTT to googleapis.com and a 160ms RTT to cdnjs.cloudflare.com. So please don't switch.

If you have users in China, then you definitely need an alternative to Google. Google has been almost completely blocked since the days leading up to the 25th anniversary of Tiananmen, so sites using Google's CDN are broken in China. Most people assumed the block would be lifted after the anniversary passed, but so far it's still in place.

We have users in China, and unfortunately CloudFlare is banned there too. Also Russia blocks some of CloudFlare's IP addresses, and Iraq AFAICT.

I am in Shanghai and CloudFlare seems to suffer from rolling blocks mostly against SSL content. We notice as we have a ecommerce site behind their service, our customer are in the EU so no bother really just a pain sometime to get their orders out... connections to Google in almost all forms is basically dead now. Weirdly I don't remember HackerNews getting blocked and thats on CF too???

There are so may factors at play in determining the amount of gain from using such a service, e.g.,

1. How widespread the usage is. The more widespread it is, the better the chance of finding the resource in the browser cache itself, instead of having to make external request.

2. Geo distribution of resource by the CDN. The closer the nearest CDN server to the end user, the quicker the delivery.

3. Popularity of CDN domain used to serve the resource. Since a DNS request is potentially involved in fetching the resource, the domain name should be widely used to keep the DNS cachces warmed up.

I am especially skeptical towards adding DNS calls to my page. One for HTML and one-two for static resources is what I have seen works best in practice, especially with modern browsers that do not have the two parallel downloads per domain limit.

Another thing to consider is parallel downloads. Last I checked, all browsers limited simultaneous HTTP calls to a single domain. Spreading downloads across domains will increase multithreaded downloading, which on most connections will increase speeds.

Parallelism is complicated: the per-server connection limit has been increased in modern browsers and will change dramatically as SPDY deployment rises[1] and multiple connections per domain becomes a complete de-optimization.

In contrast, the speed of a DNS query is relatively fixed – that initial lookup can take a long time on a cold cache (possibly seconds, particularly internationally) and nothing will transfer until it's completed, so you really need to calculate the time to last byte with that in mind. If you're talking about small, cached files, domain sharding is often a significant step back if the entire transfer can complete over an existing connection in the time it takes to perform DNS + connection for a new hostname. This is particularly interesting when you remember that modern browsers can do DNS prefetching really early so e.g. DNS for your primary domain was completed before someone even clicked on the link and multiple connections were opened as soon as they clicked.

Steve Souders looked at this last year:

http://www.stevesouders.com/blog/2013/09/05/domain-sharding-...

> A middle ground is to alter domain sharding depending on the client: 1 domain for browsers that support SPDY, 2 domains for non-SPDY modern browsers, 3-4 domains for IE 6-7. This makes domain sharding harder to deploy. It also lowers the cache hit rate on intermediate proxies.

1. interestingly, CDNJS has supported SPDY for 2 years: https://twitter.com/cdnjs/status/231227466335797249

You can use http://www.cdnperf.com/ to figure out which may be best for your circumstances (lowest HTTPS latency, downtime etc.)

Could be a good solution for projects with high volume of Russian visitors: access to many cloudflare servers is restricted by great fucking russian firewall.

Useful resource; would be great to find a general CDN performance measurement tool from each country.

When entering a new continent / country it would be good to know just how close the nearest Pop is (or more importantly what the latency is) for my chosen provider.

one major improvement of cdnjs would be where they allow a faster adding of libraries from websites such as unheap.com

Reply on news.ycombinator.com