You’ve seen this before:
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:
- Decreased Latency – file is server from a literally-geographically-closer server.
- Increased Parallelism – browsers limit how many resources can be downloaded simultaneously from a single domain, some as low as two. Since this is google.com not yoursite.com, it doesn’t count toward that limit.
- 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:
- 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.
#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/||One Hour, strictly||
|/1/||One Hour, strictly||
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.
Not Just jQuery
There are other CDN’s that host jQuery as well: Microsoft and jQuery.com 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.
jQuery.com’s version doesn’t seem to send any caching information in the header at all.