Removing (Google) CDN version of jQuery from Html5 Boilerplate?


I recently added a pull request to Html5 Boilerplate to remove the use of the Google CDN for loading jQuery.  Little did I know that it would stir up some great debate about whether using a CDN, specifically the Google CDN, was the best practice or if concatenating and minifying your code into a single file is better.

The pull request was based on 2 things, 1 was a conversation Karen Ford (my co-worker) and I had with Alex Sexton at the jQueryTO conference in Toronto. The second was a very data-driven blog post Alex referenced by Steve Webster posted in late 2011 about Caching and the Google AJAX Libraries.  In that post, Steve points out that there is generally very little performance benefit from loading jQuery from the CDN due to the amount of fragmentation that exists in what versions of jQuery are being used in the wild.

Today, Steve Souders, from whose project (the HTTP Archive) Steve Webster pulled the data for his blog post, wrote a new post, HTTP Archive: jQuery, that updates the stats from the original blog post and adds a few more observations.

His take-aways mirror Steve Webster’s, that while jQuery is being used on more sites, the penetration of any single version of jQuery has actually dropped since 2011, the most popular version being pulled from the CDN is v1.4.2, and that is being used in 1.7% of sites, down from 2.7% in 2011.  His conclusion, there are some pros (potential for cached version, no hosting/bandwidth costs, CDN performance, long cache period) as well as some cons (extra DNS lookup, extra HTTP request because you can’t combine jQuery with other scripts).

But he raises a really good point, and one that I did not (and still don’t) know the answer to when I made that pull request.  Is it better performance to load jQuery from the Google CDN (Google Hosted Libraries) or from your own server?  Part of what prompted the pull request was to see if there was any kind of definitive answer to that question.  The final conclusion:

If you’re loading core jQuery as a standalone request from your own server, you’ll probably get an easy performance boost by switching to Google Hosted Libraries. If you’re considering creating a combined script that includes jQuery, the issues raised here may mean that’s not the optimal solution.

 

In the end, I actually did know the answer, and that was Steve Sounders point – test it and see.  So I decided to do that with one of the sites I have access to.  It is hosted on Amazon, and was pulling both jQuery (v1.7.2) and jQuery UI (v1.8.2) from the Google CDN.  Here is the timing stats before (with the CDN).

Script
Size (Kb)
Total (ms)
CDN?
jQuery
72.5
137
y
jQuery UI
59.3
94
y
Scripts
(1 file)
19.2
170
n
Totals:
151
401
-

Then I commented out the references to the Google CDN and added those two files into the minifier to be built.  I was pretty surprised at the results:

 

Script
Size (Kb)
Total (ms)
CDN?
Single File
102
145
n

I got a total size reduction of 49Kb and it was 256ms faster to load the minified & combined file rather than using the CDN.

Big caveat, this is a test against a single site, and there are no guarantees that this will hold true across other sites.  As is obvious by the size of the Scripts at 19.2Kb, the site I tested did not use a lot of JavaScript.  My guess is, it would hold true for many cases, but the verdict is this: test, test, test!

Side note: I would be serving an additional 82.8Kb on the initial request by removing the use of the CDN.  If total bandwidth being served is a concern, off-loading that to the Google CDN may make good sense from a purely financial standpoint.

As to the pull request to Html5 Boilerplate project, I am very happy for the debate that ensued, but I am not going to fight hard to actually see the change implemented.  The biggest reason for that is that many developers won’t be combining and minifying their scripts into a single script file and setting a long cache on that file, and so those developers would benefit more from using the CDN, something I honestly hadn’t considered.

Whatever happens with the pull request, I definitely appreciate the time and effort the Boilerplate maintainers and those commenting put in to determine what is the best course of action!  Not to mention the time to build the Html5 Boilerplate project in the first place which gives us a forum to discuss these kinds performance questions.