Cdnjs - the missing cdn(cdnjs.com) |
Cdnjs - the missing cdn(cdnjs.com) |
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.
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?
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.)
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.
:)
This seems to work well for me.
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/
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:
The latter is rather deceptive because it's not actually testing service availability.
definitely missing ;)
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.
The CDN portion is completely independent of the website. The website is really just an index of the files on the CDN.
Round trip time is especially important when you're loading several assets in a single page.
CDNs also often provide higher availability than you can provide yourself
Using someone else's CDN is considerably cheaper than serving resources yourself. e.g. Using jquery from google cdn. Bandwidth costs for "small" javascript files start to add up once you have 100 million people loading it each day.
Not an insult, by the way, Gopher is awesome. Today the Web is an applications platform and that is not going to be reversed.
Yes, I would be shocked to be browsing the web circa 1995. Which is why I use a modern browser that supports modern technologies. I also use Ghostery with a whitelist to block tracking. That way, sites work like they should and I can browse this decade's Internet without having to go on forums and let everyone know I'm important and I'm special and every web app should work on Lynx because I said so.
I find that a perfectly reasonable attitude.
"We love that you've come to value the great material we provide, but we make money off of advertizers. If you run noscript, that's great! We totally support noscript options for those who purchase a subscription plan."
The trouble with the current CDN setup is that you only get the maximum benefit if everybody uses the same CDN, but people don't necessarily want to trust Google or whoever to host code that their site relies on. With a content-addressable system with fallbacks, you'd get all the benefits of the CDNs with none of the drawbacks.
1) add the "SIG" values to the tags in the HTML page that have SRC attribute. Be it scripts, or images, or iframes, or what not. So far, we've just bloated the page a bit with no good effect for the user.
2) update the code in the browser to calculate for each resource in the browser's cache the values of a few "frequently used" signatures, and allow the signature-based access to the content [compressed trie?], in addition to indexing the cache by the URL. Now, the "bloat markup" from step 1 starts to kick in - and you can reuse web-wide all sorts of resources - scripts, downloadable fonts, artwork, whatever. At this point the user spends the time only on the first download of the file, even if that file comes from a very slow VPS.
This approach could dramatically decrease the load on the CDNs for the frequently-repeated content, and get the latency down to near zero, so it would be much better than even the ISP-hosted CDNs.
Maybe anyone is reading this who is familiar with the FF/Chromium codebase to comment on the feasibility of such an approach ?
Aside from that, yes, this sounds pretty much like what I'm thinking of.
http://blog.cloudflare.com/cdnjs-community-moderated-javascr... https://www.cloudflare.com/apps/cdnjs
As for Cloudflare's speed, you can see cdnjs's average ping time as measured by pingdom here: http://stats.pingdom.com/4jg86a2wqei0/362854
If I'm guessing what the names of your Pingdom checks mean correctly, they seem to show CloudFlare making your response time 10ms slower. I'm assuming that cdnjs.cloudflare.com is the site with CF in front, and cdnjs.com is without, not sure if that's correct.
Basically, you need the hash and a fallback regular URL. The browser is free to grab the content using the hash however it likes, whether it's grabbing it from its cache, using the fallback URL, using another known URL for that content, or using some new delivery mechanism.