Should You Use a CDN for jQuery Libraries?

1 minute read

I frequently have people ask me whether they should store jQuery libraries in house or reference external Content Delivery Networks (CDNs) instead.

I see plusses and minuses for using the various CDNs out there. (There are several big ones: Google, Microsoft, etc.)  Reducing the ‘hits on the server’ thing is potentially one plus, but unless you are seeing significant performance issues, there’s not really a benefit there.

My biggest concern is always one of control. By using a CDN, you are deciding that you trust Google or Microsoft more than you trust yourself to store and serve up the files. Yes, that’s their business, and they have a fantastic track record, but.

Another thing is the whole firewall question. While you may be reducing the traffic on the server and from your server to the browser, you’re increasing the traffic across the firewall. In many cases, I see the network as a far bigger problem than the SharePoint server(s) when it comes to throughput.  Make sure your firewall guys can handle it and sign off on it.

Finally, by hosting things yourself, you have control over naming, version management, etc.  If there’s a new version of jQuery (or anything else), you probably don’t want to just have Google flip you to it automatically.  Given this, the whole ‘kept up to date’ argument sort of falls apart.

All in all, I’m not sold on using a CDN at all. If you want "out of sight, out of mind", then it’s a decent option, but if you have problems, don’t tell me I didn’t warn you!



  1. Using the Google CDN is a great choice if your site is public-facing. The biggest win is caching. About 10,000 sites in the Alexa top 200,000 currently reference jQuery on the Google CDN. If a user has visited any of those sites before yours, there’s a good chance that they’ll still have jQuery locally cached and it will load immediately from disk. There’s not even an HTTP request to check for a 304 not modified.

    Versioning isn’t an issue. If you reference a specific version, you’ll always get that version. They’re still hosting all the way back to jQuery 1.2.3, for example. No bit flipping to worry about.

    For an internal-only intranet, I’d agree with you though. You lose out on the potential benefits and incur the firewall risk.

    • Yeah, Dave. I can see a public facing site using a CDN, for sure. Most of the people I work with who are using SharePoint are using it inside the firewall, and they often think that a CDN is YAMB (Yet Another Magic Bullet). ;+)


  2. A key question is the users’ location. Public sites will benefit from a CDN, and so will intranets/extranets for distributed teams (I often work with teams spread across 3 continents).

    And agree with Dave, versioning is a non-issue.

  3. If you have a public facing site, use MSFT,, or Google (or any others that are out there). It’s silly not to. Do you really think your public facing site is going to have connectivity issues to something like Google? If you do, and can’t get your jQuery script, you’ve got bigger problems.

    As has been said already (and I’ll repeat it here because it is important) global distribution is key. CDNs will serve up the script from the nearest station to your client and in most cases, it’s already there. I would go to argue if you have images you should do the same, but that’s another conversation.

    As for inside the firewall, it’s silly and a waste of resources. Do you really want your user waiting for an external ISP to bring back a 30k script while your super-fast network kicks your content out at lightning speed? You paid for that hardware, use it!

    IMHO, launch Fiddler and visit your intranet home page. You better only see requests coming from that server (and potentially other servers in your domain). There should be nothing in there from Google, MSFT, or anywhere else.

    • I think we’re all agreeing here. Inside the firewall, not such a good idea, unless you think it through very well. Outside the firewall, almost certainly a good idea. (I should have pointed that out in the post in the first place.)

      The big point is the thinking it through part. You have to understand a lot of variables in all of this to get a win; it’s not just that magic bullet.

      As for actual content (the C in CDN), as Bill points out using an edge network like Akamai’s is a *great* idea for an external-facing site.

      You can also build your own “CDNs” inside the firewall which is optimized for whatever type of *relatively static* content you have. There’s no one-size-fits-all answer, though.


  4. I would never use an external CDN for a corporate site. I don’t want changes pushed to my application just because jQuery released a new version. Even if you can reference a specific version instead of the latest version, what happens when the CDN is down? My corporate sites are down? What about their security protection? What about disaster recovery and redundency? WIthout testing all of that, I’ll just serve up the extra 50 to 60K. Let them cache it from our site for use on our sites.

    • Dale:

      I think you’ll find that the opinions on this vary greatly. I’m more in your camp, but you’ll find many people on the other side. The important thing is to make informed decisions based on facts rather than conjecture.



Have a thought or opinion?