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:
See the full output from the above query if you're interested in more details.
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.
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.