[dos1]

More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc.

But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Everything else might be up and working great, but how well will the UI function if the user can't pull in jQuery? I just don't see any value in taking a dependency on these third parties for hosting JS libs and the like.

[crescentfresh]

CDN, with local fallback:

    <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.x.x.min.js" type="text/javascript"></script>
    <script type="text/javascript">
    window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E'))
    </script>

[kyrra]

If you do overall page loading times, I wonder what sort of averages you will see comparing this to hosting it locally for all requests.

When hosted locally it would result in 1 less DNS lookup, as well it could reuse an open HTTP connection to fetch the resource.

[crescentfresh]

Correct on both counts. One con of hosting multiple dependencies locally could be that parallelization of downloads is reduced. There's always a flipside and each situation warrants analysis!

So many of these discussion points are discussed at https://developers.google.com/speed/docs/best-practices/rtt

[deelowe]

I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.

[macca321]

This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.

[crescentfresh]

Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers.

However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before </body>), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.

[k3n]

You could probably wire something up in JS to handle it with reduced timeouts, e.g. an AJAX call that automatically fails after 50-100ms and proceeds to load the local version.

[jQueryIsAwesome]

A simpler solution would be to reload the page passing a parameter that you want to use other CDN; something like this: https://gist.github.com/4444636

[weego]

You've now got people wondering why their page just reloaded after half a second and a slug of unnecessary javascript in your page all for the sake of simplicity.

A simple solution would be to just link to a self-hosted version of the lib.

[jQueryIsAwesome]

False; because (if the script is inside the head of the page) the loading of Javascript is synchronous so the user will not notice any refresh at all.

[dos1]

Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request.

Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.

[crescentfresh]

> bundle them with your other scripts and save a request

There's huge merit in that IMO for single-page type applications that have many lib dependencies.

For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.

[dos1]

I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.

[jQueryIsAwesome]

Don't use unescape, is ugly and is not required if you break the close tag of "script".

    this.jQuery||document.write('<script src="js/jquery-1.8.3.min.js"></sc'+'ript>')

[crescentfresh]

Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.

[jQueryIsAwesome]

Well; I also think this is going offtopic but I have to mention "unescape" is not a JS standard but it is available in most JS engines; in the other hand literal Unicode codes in strings are part of the ES specification.

[k3n]

I think the idea is that hosts like Google (and ostensibly, Mircosoft) are going to have availability that far exceeds your run-of-the-mill website. Those big hosts generally are going to provide five 9's (or more) availability, whereas %your_random_site% is probably going to be on the order of three to four 9's, at best. So more often than not, the point of failure is going to be your website...not the CDN.

If you have the infrastructure ($$$) to support your own web services on the order of 99.999%+, then by all means host it yourself, otherwise you're most likely never going to have a problem with it (especially if you include a fallback method).

[watty]

I'm not sure I follow. Obviously if my host goes down my entire site will go down - this is not the point. The point is that when my host is up, what % of the time will my site still be down? Well if you use a CDN that % is greater than zero. If you use two CDN's the percentage is compounded.

[k3n]

And that's why you have a fallback, to fully mitigate any CDN downtime (how little that it may be). It's like a spare tire in your trunk.

[ryanmolden]

If your webserver is down what does it matter that the CDN that hosts your library scripts is up?

[k3n]

It doesn't, but that was never the point of the CDN.....

[FredFredrickson]

I don't understand this logic entirely. If your site is unavailable due to normal, unavoidable probabilities in reasonable uptime, why does it matter if the CDN is hosting your scripts or not? Your site isn't going to be around to access them.

[k3n]

It doesn't matter in those cases; it DOES matter for the 99%+ of the time that both the CDN and your site are working optimally. In theory, the CDN should provide the best all-around experience for users (caching, lower latency, parallel loading, etc.). THIS is why you have the CDN -- not as some fail-safe for when your site goes down.

[dos1]

I agree completely that your average website will have less uptime than the CDN. The problem isn't that the CDNs are less reliable, it's that it's VERY unlikely that your site will experience downtime at the same time as the CDN. This means your site reliability is the combination of the downtime of the CDN as well as your own.

[k3n]

Yeah, but if you gracefully handle those failures with local fallbacks, then the CDN's downtime is a moot point.

[dos1]

See the rest of the comments in this thread about why the fallback can be painfully slow if the CDN is down. I saw your previous comment about making an ajax request with an adjusted timeout, but this is not ideal for making cross domain script requests for a number of reasons. For one, CORS needs to be enabled. Another is that you now have to create a script tag and take the responseText and jam it in there. This is going to be slower than just creating a script tag and setting the src attr.

If you are going to have a fallback, and that fallback may take seconds to activate if the CDN is down, why not just make the fallback your primary?

[jQueryIsAwesome]

You can easily specify how much time a CDN will have to respond as you can see in my example in another comment: http://news.ycombinator.com/item?id=5003129

[kamjam]

This was what I was going to suggest also... but...

Whatever happened to using progressive enhancement techniques which meant the site would continue to work, albeit with basic functionality, for users even without JavaScript?

I understand for some sites this is not possible, but for a lot of sites it would be perfectly acceptable...

[FredFredrickson]

This is exactly my thought on the matter. It's cool that larger sites will host these scripts for you, but why should I make my site dependent on another just for a negligible improvement in speed / caching efficiency?

My feeling is that if you're going to make your site's uptime dependent on another, at least make it for something worthwhile that you can't host yourself, either because it's too demanding or too proprietary.

[k3n]

> My feeling is that if you're going to make your site's uptime dependent on another

That's a terrible idea, and of course you shouldn't do that.

You provide a fallback for the CDN...

[ChuckMcM]

"More generally, I have never understood why people use these third party CDNs for important sites."

Perhaps its not a core-competency of the company? When you're a small company you only get a few employees to work with maybe none, so you find ways to get the stuff you don't know how to do, done. Whether its contract work for design, or outsourcing operations to the cloud.