Drop Google's CDN for jquery.com?

[PeterDeKeer]

In some corners of the web people push the microsoft cdn, here we push the google cdn.
Wouldn't it be better if we just used jquery.com for the jquery cdn?
And hope a lot of libraries follow suit?

[ghost]

No, mostly because most users already have a copy of google's jquery cached in their browsers.

[roblarsen]

You're much more likely to hit the cache lottery using the Google CDN, so, no it wouldn't be better.

[roblarsen]

FWIW, most users might have a copy of some version of jQuery from the Google CDN. It's by no means a given that they will have the correct version that you have on your site.

[ghost]

As you'll see here a specific version of jQuery is requested by the site and as far as I remember you need to have this very version cached.

[roblarsen]

Yes, exactly. While 22% of the sites in the HTTP Archive are using the Google CDN now (awesome) there are still many thousands of URL combinations that make up that 22%. And even if jQuery is the dominant library in their stats (I'm downloading the 1.4 gigs right now to take a look) there are dozens of versions of jQuery hosted there. To actually hit the cache lottery a user has to have recently (caches are still tiny) visited a site that requested the exact same URL you're requesting.

For that reason I generally suggest bundling jQuery with your application files and serving a single file from a CDN or even from a static.example.com style domain (especially if you have limited geographical reach for your site or app.) My thinking is you can either bet on the unknowns of the cache lottery or you can know for a fact that you'll have one DNS look-up, one download and if you're using a CDN, similar geographical and server performance gains.

[PeterDeKeer]

Can't we (boilerplate) start with using the jquery cdn?
The MS fanboys hate using Google, and vice versa.
If we start using jquery.com, many will follow.
And the cache hit rates for everybody go up!

[ghost]

@roblarsen I'm not sure what you're saying? It seems like you're saying cache hits for Google's CDN are bad?
Having it hosting on your site means that it'll download and cache ONLY for your site. One site out of all the sites that use jQuery. If every site did this you'd have to download a new copy of jQuery 100% of the time.

[medatech]

Been seeing this conversation hit my inbox. One thing that comes to my mind is that the Google CDN and Microsoft CDN supports SSL, but appears the jQuery one doesn't. Not sure exactly how relevant that is but thought I'd mention it.

[ghost]

@medatech +1
Source if anyone is interested: http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery

[roblarsen]

@shancat I'm not saying that they're bad. I'm saying that they're probably less likely than people think. Caches are small and the number of potential jQuery URLs in the CDN is large. That's why I refer to it as a cache lottery. You have to be lucky to win.

I don't design my application architecture around things I can't control. I can either cross my fingers and hope that a user has that particular copy of jQuery loaded (which would be great) or I can design an experience which is good for the rest of my users who don't have that particular copy loaded and isn't horrible for the ones who have the golden ticket. To me, limiting the number of domains and the number of requests for all users is better than two requests and two domains for all my users except for the ones fortunate enough to have the exact copy of jQuery I'm using.

The real benefit of using the Google CDN is the speed of the server and the geographical optimization, but the geographical piece really only helps if you have a truly global audience. I shared a ton of this info a year or so ago, on another issue here where I was arguing that the better default is a locally hosted copy.

@medatech The SSL issue is big-time.

[ghost]

Yeah, completely agree most of what you said but the extra request is a non-issue on some browsers with prefetching and I think Google's CDN is more likely to be faster than a lot of client's servers any way.

[necolas]

@medatech Good point.

The MS fanboys hate using Google, and vice versa.

That's just stupid, and not something we're going to get into here.

I can't see any reason to make a change at this point in time.

[PeterDeKeer]

Just wanted to bring this up as an option, discussion. Thank you all!

[davidmurdoch]

I know this is a bit of an afterthought, but I thought I'd help hammer in the last nail on this CDN-coffin a smidge more.

Compare the GZIP sizes of jQuery 1.8.0 on 3 CDNs we're talking about:

    MS: 42141
GOOGLE: 33102
JQUERY: 33102

MS loses here probably just because they are using .NET's standard GZIP methods, which aren't very good, obviously.
MS also has the largest HTTP response headers, increasing bytes over the wire even more.

jQuery does not support HTTPS and it also doesn't set ANY expires headers (or max-age) at all (at least for 1.8.0); I'm a bit rusty on just how browsers and proxies are treating Last-Modified headers, but this probably isn't the best option.

So, Google's CDN, while it does send some superfluous response headers, does seem to be the only reasonable choice, ATM.

Now it is possible to make jQuery ~100 bytes smaller using a more aggressive GZIP compression method than what Google and jQuery are doing now. You can see for yourself here: http://www.vervestudios.co/projects/compression-tests/snippet-deflator. Keep in mind that this tool measures raw DEFLATE and does not take into account the 10-15ish additional header and trailer/checksum bytes required by GZIP.

Here is another relevant issue: #252 and its conclusion:

I think the resolution was that you should do whatever works best for you, as results may vary from project to project, depending on server location(s) and speed.

Run some A/B benchmarks on your sites then make an informed decision as to the optimal solution for each.

[ffflabs]

from my humble POV, hitting the cache lottery might be relevant for the landing page, but in terms of user experience the key factors are speed and uptime, for which I believe Google's is still better.

Also, protocol relative URL is a must for certain apps, so I'd discard jQuery's beforehand.

[roblarsen]

I agree 100% that if you're going to use a public CDN, you should use Google's.

FWIW, unless you're doing it very, very wrong, the only time the speed, uptime and chances of hitting the cache lottery is relevant is on the entry page to your site. Any subsequent page views in that session (at least) should be pulled from the cache.

[paulirish]

👍 to everything @roblarsen has said.

I've been discussing the version spread and cache lottery with the other
Google CDN folks.. I think it's a problem, but really we can't solve it
without package management (to keep you and your deps up to date)
and if you have package management, then you likely have a build process,
and if you have one of those, you're not gonna pull files from the CDN

so basically,

I think use of the CDN will decrease as sites make better and more
performant decisions.

[laukstein]

code.jquery.com EdgeCast's CDN has the best performance http://royal.pingdom.com/2012/07/24/best-cdn-for-jquery-in-2012/ (better than Google, Microsoft, Media Temple CDNs), unfortunately is still does not support HTTPS.

[roblarsen]

I'd be interested in seeing performance to Asia in that comparison. The connections between North America and Europe are much stronger than their respective connections to the rest of the world and that's where the geographic optimization is going to make a much bigger (and more interesting) difference.