static.html

— a blog about web development and whatnot by Steve Webster

The Google Libraries API is a shared CDN for popular JavaScript libraries. The theory is that the more sites that load their JavaScript libraries via these shared URLs, the greater the chance of a visitor arriving at a given website with a fresh version of the required libraries in their browser cache. That's nice in theory, but how well does that translate to the real world?

I was recently involved in a discussion on Hacker News about how widespread the use of the Google Libraries API or the static URLs it produces is for loading jQuery, and how likely it is that users will arrive at your site with a primed cache for that file.

Steve Souders's awesome HTTP Archive provides a hint of the answer to these questions: 17% of the 35,204 pages tested make use of the Google Libraries API. On the face of it this doesn't sound too bad – 17% of 35,204 pages is almost 6,000 pages, which is not to be sniffed at. However, what that fails to take into account is which libraries, and which versions of those libraries, are actually being loaded, something which is very important if you're looking to take advantage of cross-site caching.

The devil is in the details

Delving into the details shows that the 17% figure is based on the percentage of pages that include an HTTP request containing 'googleapis.com' anywhere in the URI. The actual query used to extract that stat from the test data on HTTP Archive is:

SELECT COUNT(DISTINCT pageid)
FROM requests
WHERE url LIKE '%googleapis.com%';

Google hosts a number of services on subdomains of googleapis.com, so in order to properly answer the caching question I had to download the data myself and perform my own analysis.

To work out work out what percentage of the pages tested load some version of jQuery, I ran the following SQL query:

SELECT COUNT(DISTINCT pageid)
FROM requests 
WHERE url LIKE 'https://ajax.googleapis.com/ajax/libs/jquery/%' 
   OR url LIKE 'http://ajax.googleapis.com/ajax/libs/jquery/%';

This revealed that 13% (4,689 out of 35,204) pages analysed load at least some version of jQuery. That's slightly down from the 17% headline figure, but still not too bad.

However, what we really want is the breakdown of percentages for each distinct URL (including the protocol) since browsers cache based on URL. For this, we need to modify the query like this:

SELECT url, COUNT(DISTINCT pageid) AS count 
FROM requests
WHERE url LIKE 'https://ajax.googleapis.com/ajax/libs/jquery/%'
   OR url LIKE 'http://ajax.googleapis.com/ajax/libs/jquery/%' 
GROUP BY url
ORDER BY count DESC;

This reveals that the most popular URL for loading jQuery via googleapis.com is for jQuery 1.4.2 loaded via HTTP. Tellingly, this URL is loaded by just 2.7% (945 out of 35,204) of the pages under test. The next most popular is jQuery 1.3.2 via HTTP with 1.3% (460 out of 35,204), followed by jQuery 1.6.2 via HTTP with 0.8% (285 out of 35,204).

Here's the breakdown of the usage of the top 10 jQuery versions loaded from Google's CDN:

Top 10 jQuery versions loaded from Google CDN
Version Protocol %age Count
1.4.2http2.7%945
1.3.2http1.3%460
1.6.2http0.8%285
1.4.4http0.8%270
1.6.1http0.7%247
1.5.2http0.7%231
1.6.4http0.5%192
1.5.1http0.5%173
1.4http0.4%145
1.4.2https0.4%141

See the full output from the above query if you're interested in more details.

Conclusion

At this point there really isn't much of a debate; using Google's CDN to load jQuery isn't likely to benefit the majority of your first-time visitors. You're almost certainly better off bundling jQuery up with the rest of your site's JavaScript and making sure you're serving long-lived cache-controlling headers with it.

If you still think it's worth experimenting with the Google Libraries API (or the library's CDN URLs) for your site, I urge you to use something like Boomerang to measure the end user performance of your pages both before and after you make the change. It's the only way to know for sure how much of an impact such a change will have on your actual users.

Addendum: Oddities

While investigating, I noticed a number of odd URLs that seem to include cache-busting query string suffixes:

.../ajax/libs/jquery/1.6.0/jquery.min.js?ver=3.2.1
.../ajax/libs/jquery/1.2.6/jquery.min.js?cver=3-0-0.354536628299817838 
.../ajax/libs/jquery/1.3.1/jquery.min.js?_=1321396181265
.../ajax/libs/jquery/1.4.1/jquery.min.js?ver=5704

Needless to say, including cache-busting suffixes completely eliminates any cross-site caching benefits that using a centralised service like this should provide. If you're using the Google AJAX Libraries API (or directly referencing the URLs on the CDN), I would strongly suggest you avoid this technique.