The downside is that the secure versions take longer to download if you don't get a local cache hit. I did a speed test and loaded jQuery 20 times from Google using my local machine with an unprimed cache. For the http version, the average load time was 90ms. For the https version, the average load time was 192ms. That’s over twice as slow for the SSL version. Since you can't guarantee the cache hit, it's a trade-off that doesn't have an obvious answer.
So I have an idea. For HTTPS responses that are cached to disk, 1. do we care about the security of the files on disk? 2. if so, do we do anything to actually secure this content on disk?<p>If 2 is 'No', could we perhaps encrypt the content with the SSL cert (or some piece[s] of it) before written to disk? Say you have an app you want/need to benefit from caching but the cached data contains sensitive information you'd like to make it harder to get at from a long-term perspective. Take some unique bits (or lots of bits; they're kind of small) and encrypt the cached data with it, and make a hash so you can reference where this cached item came from without explicitly noting where it came from. This would let you store the data with the knowledge that if somebody recovered a hard drive with this old data it would be difficult for them to figure out where the cached data came from and how to encrypt it.<p>I realize i'm basically asking to use public information to encrypt private data. This can't be too difficult to 'hack' around but you'd need to know what website and certificate created the cached copy (so those entries should probably leave the 'history' as soon as the browser exits). I'm not too familiar with SSL certs in general so to add extra protection you can add something like Firefox's Master Password to the encryption scheme so it's "genuinely" encrypted without data which can be found or guessed like in the SSL cert.<p>Sorry if this is off-topic, just popped in my head and now i'm curious.
The article argued against says browsers don't cache SSL resources <i>to disk</i>. This is not the same as saying they don't cache them at all. Can someone test and report back the actual behavior?<p>EDIT: I see from an HN comment by the author that he did mean on disk.
The article mentions that the HTTPS link to the resources is now default on Google's list of AJAX resources. I remember back in the day being warned that SSL connections have an appreciable overhead and so you should avoid SSL use unnecessarily. Is this no longer true? Has the overhead of <a href="https://" rel="nofollow">https://</a> become negligible?
For those that don't know what CDN is here supposed to do:<p><a href="http://blog.patrickmeenan.com/2010/03/google-to-offer-cdn-services.html" rel="nofollow">http://blog.patrickmeenan.com/2010/03/google-to-offer-cdn-se...</a><p>If I understood it correctly, the idea is to refer to the web resources in html in such a way to let the clients access them with the minimal possible latency, no matter where the clients are.