Should I use a local copy of jquery, or should I link to a copy provided by Google or Microsoft? I'm primarily concerned about speed. I've heard that just pulling content from other domains can have performance advantages related to how browsers limit connections. In particular, has anyone benchmarked the speed and latency of Google vs. Microsoft vs. local?
Also, do I have to agree to any conditions or licenses to link from a third-party?
Source: Tips4all, CCNA FINAL EXAM
Anytime you use an asset hosted by a third party you increase the number of possible points of failure in your application. You also risk potential bugs resulting from changes made to the asset (say, fixing a bug or updating to a new version) by the hosting party.
ReplyDeletePage performance can potentially suffer due to latency differences between your site and the host. Network outages between the client and the host can cause your page to fail, as can internet filtering on the part of their ISP. For instance, using code hosted by Google will cause problems for anyone viewing your site from China.
It's better for security, performance, stability and version integrity to keep all of your assets in one place. Unless you're running a ridiculously high-traffic site, you shouldn't worry about distributing your content.
It's also worth noting that while jQuery isn't exactly a featherweight include, it's not obnoxiously large and, like any JavaScript includes, should be (but is not guaranteed to be) cached by the browser.
Most recommendations I have seen have been to use the hosted version of Google or Microsoft etc.
ReplyDeleteDave Ward has a nice article explaining the reasons.
3-reasons-why-you-should-let-google-host-jquery-for-you
Decreased Latency
Increased parallelism
Better caching
See his post for stats.
Dave does point out that you should only do this for Public Facing websites.
I have been using Google's AJAX library hosting in production for several clients. Works like a charm, and is definitely the best way to go.
ReplyDeletehttp://code.google.com/apis/ajaxlibs/
I would recommend always hosting your own local copy.
ReplyDeleteThe server could go down.
The server could change version of the hosted file.
Your user's could arbitrarily create too much load on the hosted server which they may not be thrilled about.
I think its reasonable to use a hosted link when you are posting sample code you want to "work" without the user having to download jquery.
I would strongly recommend at least trying to use a hosted version of the library for the reasons others have mentioned, but at the same time, I would also recommend using your own hosted version as well.
ReplyDeleteIt may sound a bit bonkers to use both, but the 3rd party library hosts are not 100% infallible and may go down. In those rare instances, it is nice to be able to have a backup in place, and this is exactly what the HTML5Boilerplate project recommends.
Here's the snippet of code from the project that loads jQuery from google's service, and falls back to a locally hosted copy if it fails:
<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.5.1.min.js">\x3C/script>')</script>
As far as I can tell, the only possible down-side to this that doesn't exist for either the vanilla "local copy" or "3rd party" strategies is that there is an extra lookup (always) to see if the attempt to load the library from the 3rd party succeeded or not. This is a rediculously small price to pay, however, for all of the benefits this method gives you.
Another up-side is that this same strategy can be used for any multi-server hosting scenario, so you could (and I do) use this for other libraries, such as jQuery UI.
You can also extend it to use multiple 3rd-parties, so if Google was down, you could fall back to Microsoft's hosted version, and then to your locally hosted copy if needed.
Lastly, this approach is also protocol relative, so it works equally well on http and https pages without causing any browser complaints about insecure page elements.