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.
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.
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.
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???
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
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.
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.
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.
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.
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.
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.
> 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.
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.
31 comments
[ 3.7 ms ] story [ 61.1 ms ] threadIt 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...
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'm not saying they will, but really it doesn't make sense to take the risk.
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.
[1] - https://news.ycombinator.com/item?id=4912134
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.
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
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.
what is to stop you from altering the packages to steal user session cookies and post those back to your server?
"it's just very convenient".... no... it's ALSO very insecure.
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.
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
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.