Is there any REAL touchable benefit of using the Google jQuery hosted library? Or shall we just download it to our server?

What are your opinions on this?

  • 1
    A simple google search woul have provided the answer... Commented Apr 2, 2014 at 22:34

4 Answers 4


There are two major benefits to using an external CDN such as Google to host jQuery:

  1. It's faster. It will be certainly be faster than your site, and probably faster than any CDN you set up yourself.
  2. It may already be cached. Lots of sites reference jQuery on Google's CDN as well, so if they visited another site with it before yours, they won't even need to download it.

Potential downsides:

  1. The domain may be blocked (this is quite common in places like China). You can solve this by having a local fallback (see here for how).
  2. The fragmentation of version numbers is quite high, so visitors to your site may have many different versions cached, but not the one you referenced (see here for some recent stats). This is only an issue on the first page load though.
  • 3
    Can you post a reference for how to set up a local fallback? Commented Apr 2, 2014 at 14:32
  • 1
    As Zistolen points out before, another benefit is that it will download in parallel to your websites other assets. You might want to add that also to this otherwise great answer. Commented Apr 2, 2014 at 14:47
  • That's a little misleading. Browsers download assets in parallel regardless of where they are hosted, but there is a limit to the number of things they'll download from the same host at once. Commented Apr 2, 2014 at 15:11
  • I skipped that as honestly it's neither here nor there - the file may be downloaded in parallel but it's also an additional DNS lookup. Plus, whatever difference in time either of those makes is negligible anyway. Commented Apr 2, 2014 at 15:57
  • Fair enough. But on fast connections, can it not result in a faster total load time, since more of the "pipe" can be used? Commented Apr 2, 2014 at 16:06

Another downside:

Using a CDN allows operator of the CDN to track the sites visitors. That's why they don't cost money.

  • Tracking sure, but not visitors: both jquery's own and google's jquery CDN are hosted on domains that don't set or use cookies (this is probably also a performance optimization), and there's no really identifiable information in the request. The CDN provider can get an idea about IP addresses and some statistics on user agent strings and referers. This is probably valuable, but it's not by itself a huge privacy risk (if these records were correlated with another database - say personalized ads served at similar times - then perhaps it could be a means of tracking). Commented Apr 5, 2014 at 11:10
  • I think it can be taken for granted (in the case of google), that the data is correlated with other databases, since almost everyone uses google to search all the time. Same thing with google fonts: I recently tried to self-host the fonts on a server, but found out that it is very hard to do it. Google does not forbid it (Open Source), but they don't provide you with the files in a ready-to-use fashion: You can either compile them yourself (but there is no makefile), or you can forge requests to the servers that are used to deliver them normally. Both of them are not doable for a non-techie.
    – Jost
    Commented Apr 5, 2014 at 12:04
  • Perhaps. I don't have any inside information, so it's hard to say for sure. I'm certain it'll be buggy and have significant gaps, however: Most places I use the internet are NATed, and several have quite a few users with similar machines (likely identical UA strings) - it'd be impossible to know which request come from who. And of course what with adsense and social sharing buttons, they may have a more reliable means almost always, so I can imagine they don't bother. As for the fonts - I've downloaded those several times, so I don't quite understand what you mean by this being hard? Commented Apr 6, 2014 at 21:50
  • To be clear: I'm sort of assuming that the majority of website visits you make can and will be tracked by the large stat-collectors by virtue of social sharing buttons (quite pervasive) and ads, which are just about everywhere. So I just wonder how valuable possibly misleading info from heavily cached js requests is - I'm betting, not very, hence I assume they don't bother trying to personally identify people using CDN-served JS. Commented Apr 6, 2014 at 21:53
  • Its not as cached as one would think - When embedding fonts using the way google prefers it by inserting a CSS link to fonts.googleapis.com, every single page view opens a connection to google (you can see them in Firebug). Doesn't matter if cached or not. As to the download: Can you point me to a place where I can download the fonts in high-quality eot, woff, ttf and svg format (same versions google delivers, no external converters)?
    – Jost
    Commented Apr 6, 2014 at 22:36

Using CDN(s) to shard your dependencies across many servers like this in essence represents a tradeoff between bandwidth and latency, assuming you only care about performance.

I'm incidentally assuming the alternative is not simply hosting it locally, but concatenating it with a different local request - there's usually no good reason not to concatenate when you can.

If bandwidth is infinite, then you're best off NOT sharding, because you'll be as slow as your slowest service - since latencies aren't perfectly predictable, with enough services, even if they're fast, you just need one bit of bad luck to cause a slow page load.

If latency is 0, then spreading your load over many servers can improve bandwidth by utilizing many servers (not that helpful since likely the bandwidth limitations are near the clients, not the servers), but more importantly, it can reduce the amount of data transmitted slightly by increasing the effectiveness of caching.

It depends on your scenario, but I'd generally expect latency to be more of an issue than bandwidth, unless your scripts are insanely huge (which jquery is not). At that point, it's usually faster to host jquery as part of a concatenated local file.

Reasons not to host locally are e.g. when you pay for bandwidth, or you're hosting on some slow server (your connection to the client is bottlenecked on your side, not the client's), or you know your clients will have a really low bandwidth (low-end dsl or modems, say - mobile tends to have more latency issues than bandwidth issues), or your clients pay for bandwidth (e.g. mobile) and scripts are a such a noticeable portion of that that minor caching wins matter (not likely).

In any case: far more relevant will be whether you've covered the basics first; appropriate caching headers, concatenation, minification, and gzipping (preferrably with a high compression ratio). And here's the crux: if you DON'T do that, then at least the CDN will, so that's win...

TL;DR: If you have concatenation+minification+gzipping+caching all covered, then serving small scripts locally is faster than from a CDN despite the CDN's better performance - but only if you've done your homework, possibly not on the first page load, and there are definitely exceptions to this rule.

  • Incidentally, there are some byte-shavings won by using just one request: headers alone amount to almost 1kb, which on a payload of 28k isn't nothing. gzip works better with more context, which saves another 0.5k. TCP, DNS, HTTPS overheads can all easily add a KB here or there, and worse, RTT's. That's why for small files like this a CDN is a not as fast as you might think. Commented Apr 2, 2014 at 23:19

Using the jQuery hosted library by Google permits to your page to be loaded faster. Indeed, the library is loaded at the same time of your page instead of after.

  • But how does it effect the page load?
    – Leo
    Commented Apr 2, 2014 at 14:12
  • 1
    Local libraries are also loaded while the page is loaded - In both cases the download of the asset starts when the (modern) browser sees the code snippet that triggers the download, which usually happens before the entire document is downloaded. See this Firebug screenshot for an example
    – Jost
    Commented Apr 3, 2014 at 0:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.