When I see that a site tries to resolve scripts from 50 domains, for what should really just be static HTML, I generally leave.
So please. Don't use CDNs. If you want people to trust you, host your own damn stuff on your own domain.
If a website needs scripts, I expect the website to serve it from a domain which belongs to it. For most sites I visit there are at least 30, sometimes 50 scripts from various sites and domains trying to track me, slowing down my browsing experience, and sucking up my systems ram.
Disabling those causes massive speed-ups. Plus it protects my privacy.
Install ScriptNo in Chrome (or similar for Firefox). You will be shocked by the difference. And you will be shocked by the massive script-abuse currently on the net.
And no, I will not wade through that long list for each and every page I visit, to whitelist whatever CDN you have decided to put in the same trustworthyness-group as doubleclick.net.
If your site breaks with those scripts blocked, I leave.
Having that many disparat cdns is a net loss anyways by the time you do dns lookup on each one, you've lost the latency savings.
Who in this world does NOT afford to host a few small files nowadays?
The advantage of sharing a CDN (as opposed to every site having it's own) is caching. If I visit website-a.com and they include jquery.js from cdnjs.com then I visit website-b.com that also uses the same file, I don't have to download it twice and website-b.com loads faster than if it served that file itself. That's the big win, IMO, but unfortunately depends on cdnjs having a high density of use. Even still, if you can shave a 100ms of the loading of your page that can matter.
Or at the very least, we need some way to say "get this script from this URL, but only if it hashes to <this value>, since otherwise it's been compromised". Why worry about CDNs when you can design the script-switcheroo attack right out the system in the first place?
I wrote about this in June: http://rachelbythebay.com/w/2012/06/27/src/
As for the security of our system, all javascript files are verified against official sources before going on the cdn. Additionally, we have many library maintainers submitting updates to their own libraries.
Beyond that the only question remaining is our personal integrity. Like any relationship with a third party, you're going to have to decide whether trusting us is an acceptable level of risk. If past performance is any indication of integrity, we have had no security incidents since we began in January 2011.
I'm wondering what is the performance increase delivered by cloudflare. I've heard many mixed opinions and I'm at the interesection where I have to decide whether I'm using them or others.
btw - kudos to Cloudflare for sponsoring this - seems like a great way to put yourself in front of developers.
I noticed, for example, that only the latest version (3.1) of the jQuery plugin Nivo Slider is available. The last versions (<= 3.0.1) are returning 404s.
Given that the previous version was released in May 2012 that's an insanely fast deprecation policy for a CDN.
I have to guess that either I've stumbled upon a bug or minor oversight in this case, because I can't see how removing old versions that quickly would be at all a workable solution for 99% of use cases...
Digging deeper, I see that libraries are added via pull request and that the Nivo Slider library was added 11 days ago. Other libraries that have been there longer (such as jQuery) continue to have old versions.
:)
This seems to work well for me.
Well, that's hardly comforting.
How do I know their .js files won't expire out of the CloudFlare cache before the site comes up, for example?
http://cdnjs.cloudflare.com/ajax/libs/jquery/1.8.0/jquery-1.... - ok
http://cdnjs.cloudflare.com/ajax/libs/jquery/1.7.2/jquery-1.... - 404
EDIT: Looks like the URL pattern just changed slightly for jQuery. 2.72 is still around:
http://cdnjs.cloudflare.com/ajax/libs/jquery/1.7.2/jquery.mi...
Looks like they host back to 1.6.1, probably when the library was added to the project:
This saves a lot of requests and waiting time between page loads (i.e. the first page is always slower, but subsequent page loads take almost no time because there're very few (or even just 1) requests needed to make.)
The latter is rather deceptive because it's not actually testing service availability.
definitely missing ;)
