Use CDN for jQuery [#1722422]

Amidst all the discussion of how to improve the optimization of our Javascript is one option that is rarely mentioned: We use jQuery, jQuery UI, etc. Those are already mirrored on CDNs around the world by both Google and Microsoft, among others. Those CDNs are setup with super-aggressive caching. Those CDNs are used by thousands of sites around the world, which means virtually every web user is going to have those files cached locally already, with cache headers set that rarely even bother to recheck the network (assuming the CDNs are set up correctly). Sooo... Why do we bother sending all users a new duplicate copy of that file, and concatenating it into a big file so that it gets downloaded multiple times?

Let's stop trying to optimize that concatenation and just outsource the file entirely. OK, sure, if you're not connected to the Internet then you can't access the CDN. Big deal, that only applies during development. On any production site, you're connected to the Internet. We can still ship a copy of the file and offer a toggle so that people can switch from local version to remote CDN version, maybe even offer a choice of CDNs. But then we can stop worrying about "do we include jQuery or not", "do we compress jQuery or not", "do we aggregate jQuery or not". If something triggers a need for it, include the one from the CDN.

Consider how many sites will be using Drupal. Consider how many millions of people will therefore be using at least one Drupal site per day, and therefore get their jQuery from a CDN, and therefore NOT need to redownload a new copy of jQuery from every Drupal site they visit because they'll all be pointing to the same file on Google's CDN. Consider how many terabytes we save in the Inter-tubes that way, for everyone.

In fact, we could even ship only the uncompressed "Debug" version of jQuery in core, and assume that the production, compressed version comes from a public CDN.

Let's get off the island and let Google be fast for us.

Comments

Comment #1

nod_

French

Lille

CreditAttribution: nod_ commented 10 August 2012 at 15:28

That's not only about speed, using a CDN means you trust it. We shouldn't be making that decision by default for everyone. External JS file = easiest way to be hacked ever.

This is one of the topics of #1541860: Reduce dependency on jQuery actually, some good info in there, see #18, #37, #40.

Also, intranets.

Comment #2

mfer CreditAttribution: mfer commented 10 August 2012 at 15:30

I'm fairly familiar with this topic because I implemented it in the jQuery_update module. There are some things you need to keep in mind:

You need to have a local fallback for the case the CDN is not available. You can see an example of this in jquery_update or in the html5 boilerplate. This is because some firewalls (and even countries) block these CDNs. Don't just think about offline development. I would do testing around this because some browsers may wait until they timeout loading before they grab the backup and the timeouts can be as high as 20 seconds.
I would offer MS and Google as a toggle option.
You'll need to do some testing but according to yahoo research for a bit ago users often don't have warmed caches. The caches may not be as big a win as you think. What would be a nice win in the CDN integration and less time spent in network to fetch this file.

This should be a fairly easy thing for something to write. If not, I'm sure it will continue to live in contrib land.

Comment #3

Damien Tournoud CreditAttribution: Damien Tournoud commented 10 August 2012 at 16:38

I agree this could be an option, but it needs to stay an option. Among the cons that have not been mentioned here yet: delivering Javascript (== code) through a public CDN breaks the trust model of the site. To be able to use the site you not only have to trust the site, but also the CDN.

Comment #4

Crell CreditAttribution: Crell commented 10 August 2012 at 17:18

What I'm mainly after here is eliminating some complexity in the JS aggregation/compression/inclusion epic saga. If we can say "you know what, the very common libs are on a CDN, here's a toggle", we can stop fretting over optimal aggregation strategies for at least some parts of it, then get back to real work. I don't much care if it's an on-by-default or off-by-default toggle.

Comment #5

xtfer CreditAttribution: xtfer commented 12 August 2012 at 22:50

I don't have a problem with this as an option, however on several sites I have stopped using Google's jQuery as its sometimes slower than loading it with local jQuery.