You've seen this before:

<script src=""></script>

This is a way you can load a JavaScript library like jQuery directly from Google's CDN (Content Delivery Network). You can get quick copy/paste access to these from

See in that above URL how it is pointing to 1.4.4 specifically? That little part of the URL can be tweaked. Perhaps you've seen it used that way before.

/1.4.4/ Loads this very specific version of jQuery which will never change.
/1.4/ Today, this will load 1.4.4. If and when jQuery goes 1.4.5, this URL will now point to that. If and when jQuery goes to 1.5, it will link to the last release of 1.4.
/1/ Today, this will load 1.4.4. If and when jQuery goes 1.5, this URL will now now point to that. If and when jQuery goes 2.0, it will link to the last release of jQuery 1.x.

As far as I know there is no super reliable way to link to the "absolute latest" build of jQuery (e.g. that would still work if jQuery went 2.0 and include nightly builds). Let's figure out which one we should use.

A Little Reminder Why We Do This At All

The reasons for doing this are best put by Dave Ward:

  1. Decreased Latency - file is server from a literally-geographically-closer server.
  2. Increased Parallelism - browsers limit how many resources can be downloaded simultaneously from a single domain, some as low as two. Since this is not, it doesn't count toward that limit.
  3. Better Caching - There is a pretty decent chance that your visitors already have a copy of this file in their browsers cache which is the fastest possible way to load it.

To which I would add:

  1. Saves Bandwidth - The minified version of jQuery 1.4.4 is 82k. So if you had 1,000,000 pageviews with no local caching, that's 78 GB of data transfer which is not insignificant.

Caching Headers

#1 and #2 above are going to help no matter what, but caching needs a little bit more discussion. It turns out which naming convention you use is highly important to the caching aspect. Paul Irish has some basic research on this. I re-did that research and the results are below. Turns out, only linking to a direct exact version has proper caching headers.

/1.4.4/ One Year public, max-age=31536000 screenshot
/1.4/ One Hour, strictly public, must-revalidate, proxy-revalidate, max-age=3600 screenshot
/1/ One Hour, strictly public, must-revalidate, proxy-revalidate, max-age=3600 screenshot

One hour in this context is kinda useless. It does kind of make sense though. If 1.4.5 came out, anyone who is using a /1.4/ link and had a one-year expires header would still get 1.4.4 and that's no good.

Latency, Parallelism, and Bandwidth are still significant things, but pale in comparison to caching. So if caching is super important to you, linking to a direct version is your only option.

Which to Choose

/1.4.4/ Will never change, so will never break code. Best caching. Clearest to understand.
/1.4/ Possible but unlikely to break code with future updates (sub point releases more bug-fixy than API-changy). Fairly useless level of caching.
/1/ More likely to break code with future updates (point release might change things). Fairly useless level of caching.

I would say your best bet is to use the direct version links in almost all scenarios. The point-only links are pretty useless. The version-only links I could see being useful for personal demos where you kind of want your own demo to break so you know how to fix it.

Combining Scripts

If you are able to squish JavaScript files down into one file and serve them like that (like perhaps this or this) you may be better off doing that, even if they are coming from your own server or CDN. One request is almost always better than multiple.

Not Just jQuery

This same naming convention / structure is used for all the JavaScript libraries on Google's CDN. I tested MooTools and all the exact same stuff applies.

Other CDN's

There are other CDN's that host jQuery as well: Microsoft and itself. Neither of these have the same kind of naming convention so this doesn't really matter. However, do note that a direct link on Microsoft's CDN does the nice one-year cache.

<script src=""></script>'s version doesn't seem to send any caching information in the header at all.

<script src=""></script>