Quick Google CDN jQuery Tip
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:
Now suppose you just want the latest 1.4.x release, you can use (caution, keep reading):
And if you just want the latest 1.x.x release, you can use this (caution, keep reading):
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
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
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
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?
- 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.comis 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.
- 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).
Like this? Follow me ↯Tweet Follow @pfreitag
You might also like:
- jQuery UI Sortable Tutorial - January 7, 2010
- GoogleBot Runs AJAX? - December 6, 2006
- 4 Google Tricks - September 21, 2005
- Search Engine Ranking Factors - July 26, 2005
- AdSense Optimization Tips (from google) - July 21, 2005
- Google Calculator - August 12, 2003
[NOTE: The LABjs website appears to be down right now and you may need to use a search for more info.]
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.