5 ms·

Cdnjs - the missing cdn

88 points by thomasdavis 15y ago

rkalla 15y ago
Really like the idea of this community driven cdn.
pbreit 15y ago
Kudos on the recently added https support. And on CloudFlare now (vs Amazon)...interesting.
- RyanKearney 15y ago
  https was there from day 1. They're just using CloudFront so you would have to use the CloudFront url instead of the pretty one (which doesn't matter because visitors would never see it).
ch0wn 15y ago
Are there any statistics regarding the reliability and speed from different locations?
- overshard 15y ago
  It's hosted on cloudflare... just google around for cloudflare statistics.
- thomasdavis 15y ago
  http://stats.pingdom.com/4jg86a2wqei0/362854 http://stats.pingdom.com/4jg86a2wqei0/362854 Pingdom stats
  - pbreit 15y ago
    Cool. Looks like times are gradually improving.
overshard 15y ago
This seems to once again miss the point. The main point of a CDN is to speed up delivery of content. Having all of these different CDNs only increases the time it takes because you are adding in more DNS queries to the client and on top of that they are adding HTTPs support which even further increases load time because of the "handshake" that goes on. That being said, if this CDN is the only one you are using then great, that works out fine. But a CDN dedicated to only Javascript just seems kind of silly other than for passing aound example HTML files for how to code something. EDIT: Also another pitfall is that you can't compress all your JS into one big JS file saving time on requests too.
- garindra 15y ago
  The other point of a (public) CDN is to have more websites using the same kind of resources (JS/CSS files) to load them from the CDN's URLs, which in the end benefits the users by having the browsers reuse the cached version of the resources across different sites that use the public CDN.
  - dstein 15y ago
    But having fewer open HTTP connections is very likely going to result in better overall performance no matter how good this JavaScript CDN is.
    - pbreit 15y ago
      Is this speculation or proved? It's just as easy to surmise that getting the assets closer to the client will overcome any slow down from an extra connection.
      - overshard 15y ago
        It all depends on the size of the file and how fast the user's DNS server is.
      - dstein 15y ago
        It's speculation to make this claim. The burden of proof should be on them. I'd need to see a benchmark showing that making a new HTTP connection (DNS resolution and all) for a single <100KB file is worthwhile rather than sending it over your already open HTTP 'keep alive" connection.
evmar 15y ago
Note that <script src>'ing from some random website means that site can XSS you any time it wants to. (I'm not saying the owners intend for this; a third party could just as well hack their site and do the same.)
pbreit 15y ago
Pro tip: leave off the protocol to support both http and https. Example: <script src="//cdnjs.cloudflare.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script> Source: http://html5boilerplate.com/ http://html5boilerplate.com/
- paulirish 15y ago
  Secondary protip: use a DNS prefetch for even faster 3rd party asset delivery. <link rel="dns-prefetch" href="//cdnjs.cloudflare.com"> More at: http://html5boilerplate.com/docs/#DNS-Prefetching http://html5boilerplate.com/docs/#DNS-Prefetching
  - iamjustlooking 15y ago
    If you're loading the javascript on the same page you're surely going to see no benefit at all right?
    - paulirish 15y ago
      The browser can parallelize the DNS lookup, whereas running it serially and delaying the RTT for the asset will be much slower. So there is significant benefit to be had regardless. More: http://www.chromium.org/developers/design-documents/dns-prefetching#TOC-Effectiveness http://www.chromium.org/developers/design-documents/dns-pref...
      - iamjustlooking 15y ago
        Neat trick! Thanks!
- csulok 15y ago
  protocol relative URLs awesome, but be aware, because this is only good for scripts and images. stylesheets on such links are downloaded twice in internet explorer (http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/ http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem...)
phleet 15y ago
I might be alone here - but I would never use a CDN that isn't back by a company with a strong vested interest in preventing security breaches of their servers. Consider that the community CDN is compromised - if that file gets replaced with a different JS file, you've now provided an attacker an XSS hole into _every_ page using the CDN. I have a reasonable trust in Google to secure their own servers against such a compromising attack, but have no similar reason to put faith in smaller companies/services.
nikcub 15y ago
you should host this on a separate domain because your clients are setting cookies on your domain and when I hit one of your hosted js files I see all of those cookies for eg. I can see techcrunch and metric fuckton of google analytics cookies separate this from the cloudfront clients or you have a potential security problem and a definite privacy breach

88 points by thomasdavis 15y ago

rkalla 15y ago

Really like the idea of this community driven cdn.

pbreit 15y ago

Kudos on the recently added https support. And on CloudFlare now (vs Amazon)...interesting.

RyanKearney 15y ago
https was there from day 1. They're just using CloudFront so you would have to use the CloudFront url instead of the pretty one (which doesn't matter because visitors would never see it).

ch0wn 15y ago

Are there any statistics regarding the reliability and speed from different locations?

overshard 15y ago
It's hosted on cloudflare... just google around for cloudflare statistics.
thomasdavis 15y ago
http://stats.pingdom.com/4jg86a2wqei0/362854 http://stats.pingdom.com/4jg86a2wqei0/362854 Pingdom stats
- pbreit 15y ago
  Cool. Looks like times are gradually improving.

overshard 15y ago

This seems to once again miss the point. The main point of a CDN is to speed up delivery of content. Having all of these different CDNs only increases the time it takes because you are adding in more DNS queries to the client and on top of that they are adding HTTPs support which even further increases load time because of the "handshake" that goes on. That being said, if this CDN is the only one you are using then great, that works out fine. But a CDN dedicated to only Javascript just seems kind of silly other than for passing aound example HTML files for how to code something. EDIT: Also another pitfall is that you can't compress all your JS into one big JS file saving time on requests too.

garindra 15y ago
The other point of a (public) CDN is to have more websites using the same kind of resources (JS/CSS files) to load them from the CDN's URLs, which in the end benefits the users by having the browsers reuse the cached version of the resources across different sites that use the public CDN.
- dstein 15y ago
  But having fewer open HTTP connections is very likely going to result in better overall performance no matter how good this JavaScript CDN is.
  - pbreit 15y ago
    Is this speculation or proved? It's just as easy to surmise that getting the assets closer to the client will overcome any slow down from an extra connection.
    - overshard 15y ago
      It all depends on the size of the file and how fast the user's DNS server is.
    - dstein 15y ago
      It's speculation to make this claim. The burden of proof should be on them. I'd need to see a benchmark showing that making a new HTTP connection (DNS resolution and all) for a single <100KB file is worthwhile rather than sending it over your already open HTTP 'keep alive" connection.

evmar 15y ago

Note that <script src>'ing from some random website means that site can XSS you any time it wants to. (I'm not saying the owners intend for this; a third party could just as well hack their site and do the same.)

pbreit 15y ago

Pro tip: leave off the protocol to support both http and https. Example: <script src="//cdnjs.cloudflare.com/ajax/libs/jquery/1.6.2/jquery.min.js"></script> Source: http://html5boilerplate.com/ http://html5boilerplate.com/

paulirish 15y ago
Secondary protip: use a DNS prefetch for even faster 3rd party asset delivery. <link rel="dns-prefetch" href="//cdnjs.cloudflare.com"> More at: http://html5boilerplate.com/docs/#DNS-Prefetching http://html5boilerplate.com/docs/#DNS-Prefetching
- iamjustlooking 15y ago
  If you're loading the javascript on the same page you're surely going to see no benefit at all right?
  - paulirish 15y ago
    The browser can parallelize the DNS lookup, whereas running it serially and delaying the RTT for the asset will be much slower. So there is significant benefit to be had regardless. More: http://www.chromium.org/developers/design-documents/dns-prefetching#TOC-Effectiveness http://www.chromium.org/developers/design-documents/dns-pref...
    - iamjustlooking 15y ago
      Neat trick! Thanks!
csulok 15y ago
protocol relative URLs awesome, but be aware, because this is only good for scripts and images. stylesheets on such links are downloaded twice in internet explorer (http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/ http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem...)

phleet 15y ago

I might be alone here - but I would never use a CDN that isn't back by a company with a strong vested interest in preventing security breaches of their servers. Consider that the community CDN is compromised - if that file gets replaced with a different JS file, you've now provided an attacker an XSS hole into _every_ page using the CDN. I have a reasonable trust in Google to secure their own servers against such a compromising attack, but have no similar reason to put faith in smaller companies/services.

nikcub 15y ago

you should host this on a separate domain because your clients are setting cookies on your domain and when I hit one of your hosted js files I see all of those cookies for eg. I can see techcrunch and metric fuckton of google analytics cookies separate this from the cloudfront clients or you have a potential security problem and a definite privacy breach