Pros and cons of hosted scripts

Question

I have seen some developers use hosted scripts to link their libraries.

cdn.jquerytools.org is one example.

I have also seen people complain that a hosted script link has been hijacked.

How safe is using hosted scripts in reality? Are the scripts automatically updated? For example, if jQuery 5 goes to 6 do I automatically get version 6 or do I need to update my link?

I also see that Google has a large set of these scripts setup for hosting.

What are the pros and cons?

Answer 1

Pros

• Your scripts are loaded faster. If you have an abundance of resources that need to be loaded from a single domain, your browser will typically bottleneck this so that you only have a handful of parallel requests to the same host. So if you're loading sixteen separate scripts, multiple images, and multiple CSS documents there is going to be queue as each resource waits its turn to be loaded. (Definitely look into concatenating your CSS and Javascript files - loading only two script resources will be significantly faster).
• If you spin those resources off into a separate domain, however, your browser won't have a problem opening up additional connections to that server, which means that more resources are loaded concurrently resulting in faster page execution. You're also letting a different server handle part of your page loading, which is good for your server that is probably working on several script-execution requests as it is.
• Additionally, these CDN servers (content devivery networks) are configured to operate as CDNs. They are typically cookieless (for smaller packet sizes) and are set up with an extremely lightweight server that concerns itself wholly with serving resources and caching commonly used resources and not so much with the day-to-day lifting that something like a bog-standard Apache server will perform.
• Using a CDN like Google or Akami has other benefits as well - Google especially has servers all over the world and its routing systems are smart enough to pair a request for a resource with the closest geographic copy that exists. Your server might be trying to serve jQuery.js to Vladimir over in Russia - Google probably has the same resource down the street from Vladimir, decreasing latency.
• Also, since so many website already use these CDNs, there is a high likelihood that the resource you are serving has already been cached by the user. jQuery.js from your server and jQuery.js from Google's server are not treated as the same file, no matter if they are exactly the same - if you load from Google, it will be able to use the cached copy from the previous site that the user visited.
• The files themselves will not change, especially for script resources like Javascript frameworks. If a new version comes out, Google will continue to host the old version (no matter how heinous the bugs) specifically so that the CDN will continue to operate normally and not serve any bad requests. This is why any CDN file is full suffixed with the appropriate version number.

Cons

1. There is the possibility of your CDN not being available. The chances, however, are slimmer than your site going down, probably. Larger CDNs like Google and Akami have multiple layers of fail-over.
2. Creating a new connection might not be worth it if you only have one or two resources to load from your own server.
3. You do not have any sort of control over the file being served, so using your custom version of jQuery or whatever else you are trying to load is out, unless you are paying for your own CDN.

Security

I would recommend this El Stack post plus a good amount of Googling of the subject. Each CDN will be different, although in a nutshell I think that this would be a minor concern.

Answer 2

Something no one mentioned is yet another tracking option for Google. They're not offering all these services at no cost for no reason. AdSense and Analytics are quite enough and at least those can be filtered. That's a big con in my book.

Answer 3

Pros:

• You don't have to pay for bandwidth related to serving the files and generally

Cons:

• You are subject to the available of the hosting provider you are using (if they go down for whatever reason, your down too).
• You forced to whatever version(s) of the scripts the hosting providers have

There are other benefits of using a CDN but they don't relate directly to using a 3rd script hosting service.

Answer 4

As far as best practices go, the common approach to optimize page loading is to bundle all of your JS resources, due to the constrained number of connections towards a single domain as Jarrod mentioned, and setting a far future expires header in the response.

What CDNs bring to such a mix, especially the popular ones, as Jarrod pointed out also, is that the user would have already previously accessed the URL and can retrieve the JS resource immediately from his client's cache without even requiring to establish a connection.

To that effect, if we all used CDNs and employed best practices, we can save the user from retrieving an additional ~10-50KB when they initially access our URLs and allow them to load their pages faster.

I would strongly recommend to use CDNs for two reasons: the cons Jarrod mentioned are there, true, but completely insignificant and if your already bundling your sources into a single document, you'll force everyone to retrieve, say, the static jQuery portion of the document (~33KBs) every time you update one of the bundled resources.

I don't know how important that sounds to you, but with huge user bases this leads to a significant bandwidth cut and significant savings, bot of which we can divert to more pressing matters, such as streaming porn and buying beers.

Answer 5

Don't Do It

Personally, I would not rely on third party hosted scripts. If you leverage other peoples scripts you are at their mercy. There are several things to consider:

1. If their site goes down your page may time out or error out.
2. If they go out of business and turn off hosting you just lost all that functionality
3. If they get hacked, you could also get hacked.
4. Cross-site scripting can play havoc with SSL certificates
5. Page load times can increase dramatically
6. If the interface changes you need to modify all the function calls

It's safer to host the code on your own site, trust me. You only need to get burned once and have 250 websites that you built and host start acting funny because you relied a third part hosted script that stopped working.