I was always tempted by using a jQuery custom build (and reducing its size) instead of the generic build. However, one strong argument against it is that 3rd party CDN versions are faster and could be already cached.

Let’s do a proper comparison of the pros of each solution, analyzing some data from real-world websites.

Custom build pros

  • smaller size (up to 65% less, 37KB vs 84KB minified)
  • smaller footprint
  • 1 less HTTP request if combined with all other page scripts

3rd party CDN pros

  • served over high quality CDNs (es: Google)
  • parallel download
  • may be already cached

Is CDN version really worth?

The biggest argument for the CDN option is the “already cached” opportunity: a download time of ~0ms is web developers’ dream. Looking around, there are probably more than 50 million websites using jQuery and lots of them are actually getting jQuery from Google CDN. So the chances that jQuery would be already cached sounds high, aren’t they? However, that is not the truth.

jQuery URLs fragmentation kills the probability of hitting cache

In order prove that jQuery popularity is not enough to assume a high probability of it being already cached, we can use Google BigQuery and the HTTP Archive to get data from the top 300.000 Alexa websites.

Query against 2014/12/15 requests data
select url, count(distinct(pageid)) as count
from [httparchive:runs.2014_12_15_requests] where
url LIKE "%://ajax.googleapis.com/ajax/libs/jquery/%"
group by url order by count desc;

The result of the above query shows more than 100.000 unique urls. The reason why this number is higher than the available jQuery’s versions is that minified, unminified, https and urls with parameters are cached separately. Moreover, top versions are:

version count of all websites
1.10.2 6929 2.30%
1.7.1 6439 2.14%
1.7.2 6340 2.11%
1.8.3 5734 1.91%
1.9.1 5558 1.85%
1.11.1 5039 1.61%

The latest version (Dec 2014) is only 6th, with nearly half of the popularity as 1.7.1. And jQuery modern 2.1.1 is only 27th, with 1155 counts (0.38%). So, you can clearly see that you have to be quite lucky in order to get a cached version (less then 2% chance). Is it still worth against the SPOF probability?

Custom build tweaking

The main argument of custom builds is that you can opt out modules you don’t really need. Getting rid of unused stuff is really easy.

Not making AJAX requests? Remove ajax. Querying the DOM using simple class/id selectors (as you should)? You can probably and safely remove sizzle. Non using JS animations? Remove effects. And so on.

Most of the time you are actually using only event delegation, DOM manipulation and CSS/attributes functionalities. If that’s the case then try this custom build which will be 45KB minified (half size the full jQuery):

grunt custom:-ajax,-deprecated,-effects,-event/alias,-wrap,-exports/amd,-core/ready,-deferred,-queue,-callbacks,-sizzle

The rule is that any module (filename in /src) may be excluded with the exception of core and selector.

CDN or not?

If you are looking for the maximum performance, I would suggest you to concatenate a custom build of jQuery with all your other scripts. Moreover, if you are already using a CDN for serving your static files, then you should see performance benefits under every condition.

However, if you are not using a build script (you should!), Google CDN will be faster than your web server in almost every scenario, so it is better to stick with the generic CDN version (but remember to add a fallback!).

PS: I’m not even rising the question around the need of jQuery, because sometimes you have to include it.