I want you to be right about the shared caching benefits – I get the theory – but I’m not sure that just looking at how sites are built gives us enough information.

The piece we’re missing is ‘how long do the libraries live in the browser cache’ – the Yahoo work showed how often even a high profile sites assets drop out of the cache.

Now in theory files that are shared between sites should stay in the cache longer but doesn’t that heavily depend on how often and in what order people visit sites?

I think the ideas you’ve had on how caches should work could be really beneficial for people using the library CDNs.

When it arrives the ResourceTiming API may also offer site owners an insight into what benefits they’re users are getting (or not) from hosting on a library CDN. (partly depends on whether the API is opt in or out too)

I guess the advice for site owners might be “use the location/version of jQuery that’s most commonly used by the most popular sites” but of course that also comes with tradeoffs!

Web performance is such a great world to be in…

(BTW planning on borrowing your graph showing how transfer size has changed over the last year for a presentation on performance in late Feb/early Mar – will forward the link when it’s done and will of course credit you)

I read this article again and found the update :”Update Oct 12: Home screen apps in iOS 5 do not exhibit this problem. Blaze.io reports that home screen apps use caching as expected. They also have faster JS likely do to the integration of the Nitro engine.”

As I tested it in my iPhone4S with iOS 5.0.1 today, if the web page is expected to be launched with full screen from home screen, it still cannot leverage cache.

That is, if there is “” in , there is no If-Modified-Since header in all requests from the page launched from home screen.

If there is no full-screen, then yes there is improvement in iOS 5. Expires header works for page from home screen.

Can you please double check it and update your findings?

Thanks,
-Morgan

Can it be because jQuery size growth or is it because of in-house code-base grew bigger?

Couple quick links on the topic:
http://mathiasbynens.be/demo/jquery-size
http://docs.jquery.com/Downloading_jQuery#Current_Release

My point still stands: using the Google Libraries API provides benefits of a geo distributed CDN and caching across websites.

Regarding geo distributed CDN: If your website already has a good CDN this might not make a difference, but if you’re serving from a single geo location you’re probably better off using a CDN.

Regarding caching across sites: It’s definitely true that the probability is less for a single version of a file, but the probability is still higher than if you host it only on your own server. For example, looking at yesterday’s batch run, “http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js” is requested on 114 of the top 10K websites. That significantly increases the probability of it already being in the cache compared to requesting it from your own server, especially if you’re not in the top 10K.

I agree with you that this might not make a huge difference, but I still think it’s a good idea especially for sites that don’t have a CDN and are outside the top 10K.

Have you also looked at web fonts? (eg *.eot). They also force sequential downloads and unfortunately are becoming more and more prevalent.

A while back @spjwebster (works for LoveFilm in the UK, I think) did some digging into the usage of libraries hosted on Google’s CDN and came to the conclusion that it’s not really a rosy picture at all – http://statichtml.com/2011/google-ajax-libraries-caching.html

Main problem is that many sites rely on specific versions of a library (say jQuery) and due to this it’s unlikely the version they need is already in the cache.

I’ve also seen some examples where the cost of going to the Google CDN i.e. DNS lookup, TCP connection setup, is actually slower than serving jQuery form the origin site.

@andydavies

It should help developers set priorities for improving their websites!

Cheers,
Joakim