> So, if you are using, for instance, the URL "//code.jquery.com/jquery-2.0.3.min.js" on your site, and the user has already visited a bunch of sites which are using that URL for their jQuery (highly likely), it means that there is no re-download because the browser already has the DNS and JS cached.
Have you actually measured this? I've found that the results are lot murkier because not every site uses the same CDN or the same version of jQuery, so a user might have a bunch of different copies cached and still need to load the version you use, and many browsers – particularly on mobile – still have very small cache size limits so the fact that they downloaded jQuery yesterday doesn't mean it's still cached when they visit your site again today. This becomes increasingly dubious for any library less popular than jQuery.
This also doesn't help as much as you think for latency: by the time the browser is requesting that copy of jQuery, it already has your site's DNS resolved and almost certainly has at least one connection already established to your webserver. Restarting those processes for another server adds a non-trivial amount of latency – more so for HTTPS — which is acceptable if you're going to be making many requests but might take longer than simply transferring something like jQuery over an existing connection, particularly for wireless users or anyone using SPDY. This is fine for something which doesn't block rendering or which can stream but for something like CSS/JS in the critical path you really need real world monitoring to see how well your CDN is actually performing.
Ok, but trade that off against the latency for sending cookies and whatnot, and I think the difference is likely trivial.
If we look at the headers for jQuery 2.0.3, we get Expires:Thu, 31 Dec 2037 23:55:55 GMT, which means that it will not expire.
You make a good point in the fact that mobile won't have so much room to cache, however, I'd imagine this will increase as devices get more space and whatnot - in Android 4.4 with the latest Chrome Beta, I tried a few sites I'm using CDN on and got 304 for pretty much all CDN'd stuff:
> So what I'm saying really is I think that whilst you have good arguments, I think that things are continuing to get better and better :)
Yeah, I don't want to come across as a complete downer on this – the situation is easily better than it's ever been with CDNs becoming not just available but cheap, distributed DNS a turnkey service, etc. etc. Working on a global website for awhile has definitely reminded me that performance / reliability work hits diminishing returns unless you have have near-Google budget.
> That said, once everyone's on LTE, perhaps we don't even have to care ;)
Have you actually measured this? I've found that the results are lot murkier because not every site uses the same CDN or the same version of jQuery, so a user might have a bunch of different copies cached and still need to load the version you use, and many browsers – particularly on mobile – still have very small cache size limits so the fact that they downloaded jQuery yesterday doesn't mean it's still cached when they visit your site again today. This becomes increasingly dubious for any library less popular than jQuery.
This also doesn't help as much as you think for latency: by the time the browser is requesting that copy of jQuery, it already has your site's DNS resolved and almost certainly has at least one connection already established to your webserver. Restarting those processes for another server adds a non-trivial amount of latency – more so for HTTPS — which is acceptable if you're going to be making many requests but might take longer than simply transferring something like jQuery over an existing connection, particularly for wireless users or anyone using SPDY. This is fine for something which doesn't block rendering or which can stream but for something like CSS/JS in the critical path you really need real world monitoring to see how well your CDN is actually performing.