Quick Google CDN jQuery Tip
By Pete Freitag
Here's a quick tip if your using Google's Content Delivery Network (CDN) for serving up jQuery (or other scripts).
So if you want jQuery 1.4.4 you can use a url like this:
http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js
Now suppose you just want the latest 1.4.x release, you can use (caution, keep reading):
http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js
And if you just want the latest 1.x.x release, you can use this (caution, keep reading):
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
I would think that using a less specific version number (like 1.4 or just 1) would result in a higher cache hit ratio for your visitors. One drawback to this would be that when a new version comes out your users will start using it without giving you a chance to do any testing.
Update: However if you take a look at the comments, one of my readers points out that there is a big difference in the Expires
http header when using the full version, vs using a version shortcut. Here's what the HTTP headers look like on a request for 1.4.4
:
Date: Thu, 13 Jan 2011 16:41:02 GMT Expires: Fri, 13 Jan 2012 16:41:02 GMT Cache-Control: public, max-age=31536000
Now here's what they look like when you request just the 1.4
:
Date: Fri, 14 Jan 2011 16:45:21 GMT Expires: Fri, 14 Jan 2011 15:45:21 GMT Cache-Control: public, must-revalidate, proxy-revalidate, max-age=3600
When requesting 1.4.4
we get a file with an expiration date of next year, and the Cache-Control
with a max-age
of one year.
Now when you look at the request for 1.4
you will notice that the Expires
date is prior to the Date
header, and the max-age
specified in the Cache-Control
header is only one hour.
What are the Pro's and Con's to using Google's CDN to serve up jQuery?
- Pro's
- Google's CDN has a very low latency, it can serve a resource faster than your webserver can.
- There is a good chance that the user may have a cached copy of jQuery from google CDN, so they won't need to download it again.
- Chance are good that the dns lookup for
ajax.googleapis.com
is cached by the user as well. - Because the script is on a separate domain, modern browsers will download the script in parallel with scripts on your domain.
- Google's CDN also works with HTTPS, so you can offload the SSL processing to google's server.
- Con's
- Security - If someone hacks google's CDN then they can run javascript on your site.
- Additional DNS request may be required, but I'm betting the Pro's make this negligible in most cases.
- May be slower if your site is internal (an intranet for example).
Do you have any other Pro's or Con's to using Google's CDN for common javascript files?
Quick Google CDN jQuery Tip was first published on January 13, 2011.
If you like reading about google, cdn, jquery, tips, or ajax then you might also like:
- jQuery UI Sortable Tutorial
- GoogleBot Runs AJAX?
- Tracking JavaScript Events with Google Analytics
- 4 Google Tricks
Discuss / Follow me on Twitter ↯
Tweet Follow @pfreitagComments
In theory, this should be very rare, but I have had problems serving the Dojo Toolkit from the Google CDN. In fairness, if you don't create a custom build of Dojo you can end up having to download a huge number of files. In my case it seemed like any latency on the CDN caused my site to slow to a crawl. This problem would probably not be that noticeable if you are only including the single jQuery file, but it's worth noting that latency problems can happen on the CDN.
@David - you can always fall back to a local copy of jQuery if the CDN is down.. have a look at the html5 boilerplate code (http://html5boilerplate.com/) for example..
I'd highly recommend *always* pointing to the specific version of jQuery you've tested your site against.
There are just too many changes between jQuery point releases that could impact your code in a way that's difficult to track down. There's nothing worse then users reporting your sites not working, yet you know that you haven't made any changes, only to eventually track down the issue as a change to some external files being served up that you can't control. While this could happen if the CDN is down as well, at least then you'll see more obvious JS errors instead of the more subtle changes that can occur if behavior changes.
I've just been using jQuery long enough (since like jQuery 1.1) I've just seen enough changes in point releases that caused me to update code to realize it's a bad thing to automatically point to the latest version of jQuery in a production environment.
The only time I would think about using this technique is for a development version of a jQuery plug-in or for a test environment, where you just want to make sure your code works w/the latest stable version.
@Geoff, I took a look at the expires headers on the short version number files and they have an expiration date prior to the current date!
@Dan - That is a good point too, in my experience I haven't had much if any issue between minor versions, but I've only been using it since 1.3.
Are you sure you are serving your single js code gzip'd on S3? gzip speeds up page load times significantly but S3 doesn't have standard support for gzip and trying to force it on all browsers can be problematic.
Instead I would suggest checking out google's new google storage for developer's service, it is feature compatible with S3, but unlike S3 they automatically gzip css/js when possible and even sets correct content-type headers. I've even found load times to be better then S3.
I'd also recommend google's closure compiler service when minifying and combining your source, it has the best compression rate and can even optimize the code for faster performance.
Cheers
http://LABjs.com/
[NOTE: The LABjs website appears to be down right now and you may need to use a search for more info.]