jQuery’s Content Delivery Network: You Got Served!

Posted on by

MaxCDNIn 2013, MaxCDN joined the jQuery Foundation and stepped up to provide Content Delivery Network (CDN) services for the jQuery CDN at code.jquery.com. Files can now be requested through both HTTP and HTTPS (SSL) protocols, either to download to your own servers or to use directly on production web sites. MaxCDN’s infrastructure can reliably deliver jQuery files through a worldwide high-speed collection of servers to minimize round-trip time.

Why a CDN is Useful to Developers

The obvious benefit is that the MaxCDN network is much faster than the average server, and geographically distributed so that round-trip times are kept low. Yet there is another subtle benefit. Many web sites simply serve up all their content (HTML, CSS, scripts, images, and other assets) from the same domain. This can create a bottleneck on both the browser and the server. Downloading content from multiple domains, known as domain sharding, can improve performance. Just remember that as with any good thing, going overboard is a bad idea. Some research shows that just two domains may be the sweet spot. Use a tool like WebPageTest to test your site to get the best results.

Why a CDN is Useful to jQuery Projects

jQuery projects serve out a huge number of bytes, especially on days when a project makes a new release. When developers rush to download the latest version, we want to be able to handle the load. GitHub does a great job of supporting our development cycle and working project files, but it is not designed to serve up billions of copies of our production files. Google and Microsoft also provide CDNs, but it can take several days between the time a project makes a release and the time the files appear on those CDNs. Third-party CDNs also have their own rules about which files can be placed on the CDN, for example they don’t post pre-release versions. The jQuery CDN allows us full control over timing and content.

Serving Billions of Files, Trillions of Bytes

We thought we were serving a lot of files, but some statistics from MaxCDN really drive home the point. In the last five months of 2013, the CDN served more than 82 billion files, exceeding 3.6 petabytes. We sent out enough bytes to completely fill 3,269 1-terabyte disk drives! An average day on the CDN has us serving up about 20 terabytes of data.

Here are the ten most popular files requested from the CDN:

# File name Hits
(billion)		 Size
(terabytes)
1 jquery-latest.js 6.36 404.65
2 jquery-1.9.1.min.js 5.93 193.96
3 jquery-1.7.2.min.js 4.95 154.50
4 jquery-latest.min.js 4.45 116.08
5 /ui/1.10.3/jquery-ui.js 4.18 484.58
6 jquery-1.9.1.js 2.45 178.54
7 jquery-1.10.1.min.js 2.27 71.62
8 jquery-1.7.1.min.js 2.26 78.05
9 jquery-1.4.2.min.js 2.07 39.80
10 /ui/1.10.3/themes/smoothness/jquery-ui.css 1.55 9.83

There are some encouraging signs here. Some of the most popular files are the minified files, as they should be for a production web site. It’s also encouraging that recent versions of jQuery Core (1.9.1 and 1.10.1) are high up on the list. That means a lot of jQuery developers are keeping up with the features and bug fixes we’ve been adding.

The most commonly requested file is jquery-latest.js, which automatically updates whenever the jQuery Core team releases a new version. Developers should never use jquery-latest.js or jquery-latest.min.js on a production site, it is primarily meant for testing. Similarly, the full jQuery UI build at position 5 is the latest version, but that file may not be a good fit for production sites needing only a few jQuery UI widgets. A minified copy with just the needed widgets can be built on the download builder page.

Counting on the CDN

Thanks to MaxCDN’s contribution, the jQuery Foundation has a content delivery network that offers reliable high-speed access to all of our project files. The files at code.jquery.com serve as the official repository for all jQuery project releases. You can either download the file for local use, or reference our domain directly from your own web pages to take advantage of the CDN and domain sharding.

18 thoughts on “jQuery’s Content Delivery Network: You Got Served!”

  1. Roger on said:

    Those numbers are insane! Do people run without caching?

    I’ve found the jQuery CDN is relatively unknown and most people are still using Google and MSFT CDN endpoints. It’s hard to believe the jQuery CDN numbers are so high given that there.

  2. Justin Dorfman on said:

    @Roger I can confirm the numbers are indeed real. It makes me wonder how many requests Google and Microsoft handle. I really wish they were more transparent with that data.

  3. John on said:

    What’s the advantage of using the code.jquery.com CDN instead of Google’s CDN? A significant downside is that code.jquery.com’s SSL configuration is currently insecure. According to https://www.ssllabs.com/ssltest/analyze.html?d=code.jquery.com it is supporting anonymous (insecure) cipher suites, resulting in a grade of F. On the other hand, Google’s CDN domain gets a grade of A: https://www.ssllabs.com/ssltest/analyze.html?d=ajax.googleapis.com

    The EFF has written extensively on the importance of (actually secure) https connections, and is publicly keeping track of progress (see https://www.eff.org/deeplinks/2013/11/encrypt-web-report-whos-doing-what for example).

  4. Justin Dorfman on said:

    @John Thanks for bringing this to our attention. I will be talking to our engineers today to see how we can fix this.

  5. Matt on said:

    I’ve been running some performance testing on gtmetrix.com
    It has a few advisories regarding using code.jquery.com hosted resources

    it asks for :
    Specify a Vary: Accept-Encoding header
    The following publicly cacheable, compressible resources should have a “Vary: Accept-Encoding” header;

    Is this configurable by me in my htaccess, would you need to make the changes?
    I’ve checked the asp.net hosted version and that does not give a vary accept advisory on gtmetrix

    And Minify JavaScript
    Minifying the following JavaScript resources could reduce their size by 87B (1% reduction)

    I know it’s under only a few bytes, but doesn’t every byte count, particularly when serving a large volume of data from various sources

    Thanks

  6. John on said:

    @Justin Sure thing, hope the SSL gets fixed. Should we keep an eye on the comments here for updates?

  7. gkumar on said:

    Hi,
    Instead for server 404.65 TB of jquery data, Why can’t it be servers thru web browsers iteslf ?
    Why don’t we load all the popular js f/w bundled inside bowser and the html file refer it locally?

    Is it not possible; un necessary wasting 404.65 TB of bandwitdth !!!

  8. Justin Dorfman on said:

    @Matt I will talk to the jQuery infrastructure team about the Accept-Encoding header. It is a very simple fix that I wrote about last year (http://j.mp/1fRJMDJ).

    @John Yes we will update this thread as well as our blog. We are testing the new ciphers this week to make sure performance isn’t hindered in any way.

  9. Justin Dorfman on said:

    @Matt worked with the infrastructure team and “Vary: Accept-Encoding” header is now available on all assets.

    curl -I code.jquery.com/jquery-1.10.2.min.js
    HTTP/1.1 200 OK
    Date: Mon, 20 Jan 2014 18:47:22 GMT
    [clipped]
    Vary: Accept-Encoding

  12. Matt on said:

    @justin

    Thanks to both you and the infrastructure team for the update. It works perfectly.

    Was there any thoughts on additional minification?
    I think it’s to do with the comment tags on line 1 and 2

  14. Justin Dorfman on said:

    @Matt we just host the files that are given to us. I assume you are talking about this line:

    `/*! jQuery v2.1.0 | (c) 2005, 2014 jQuery Foundation, Inc. | jquery.org/license */`

    That should stay IMO to give the authors credit for their work as well as state the license agreement.

  18. PhistucK on said:

    The numbers seem to indicate not enough caching is happening. Really, they are too huge to be true, something is off or wrong here.