I don't usually like to host my JavaScript elsewhere such as on the Google CDN. Are there any web standards in the works where you can specify a hash of a file to be cached regardless where it is?

I haven't seen one, but that would be very beneficial, it would not only make everything faster, but also avoid the privacy concerns and remove the additional point of failure that external CDN creates.

Absolutely. Actually in that case we could just do something like this:

    <link rel="stylesheet" hash="b6792c2dcaafc7678f18236f6e7289152756a14f" href="...."></link>

Now that I look at it.. where do we suggest this to the web people?

You could use a magnet "link" (which is really just a hash anyways) to pull the file from the Kademlia DHT.

well, that would not work well with backwards compatibility, also it adds extra protocol to implement to browser vendors (extra bugs, here they come :)

Why, pray tell? Isn't the Google CDN:

- faster for people in different geographic areas

- at least as reliable as your infrastructure

- already cached (this would be nullified by your proposal)

I ask because normally I wouldn't think twice about using the Google CDN libraries.

you are right about first, but >- at least as reliable as your infrastructure this doesn't mean that Google CDN is down the same times that your server is, thus it adds downtime (or time when something is broken in the site), i.e. if your server doesn't work, nothing works, if your server works but CDN doesn't, again something is broken and if this time doesn't overlap, it is just additional risk, even if tiny one. Also, what happens when Google decides to charge for use of the CDN?

Ignoring the last point, this is probably why the HTML5BP loads from the CDN but fallsback to a local version if the CDN can't be reached.

It's fairly trivial to load jQuery/other libraries from the Google CDN and fall back to a local copy if it fails as long as you're not using async/deferred.

We've got it baked into our boilerplate.

If Google decides to charge for use of their CDN, then I wish them luck. They don't have any billing information and short of serving a bastardized jQuery (simply not serving it will trigger the fallback) our projects will continue as they've always been.

You're also passing off your user's information to someone else. It's a minor concern, but for some people that might be important.

Genuinely interested - what information?

A 2007 Yahoo investigation found 40-60% of Yahoo's users came to the site with an empty cache, accounting for 20% of page views. Empty cache experience is important.

http://www.yuiblog.com/blog/2007/01/04/performance-research-...

My browsers are all set to dump cache and cookies upon exit.

I'd be interested to see if this has changed much in the almost 7 years since that study was done.

It depends on how much the browser caches have grown to compensate for page bloat. Ie8 and below had a limit of 50 mb for all sites, ie9 upped it to 250 mb.

>Is 'page size' alone enough to worry about this sort of thing? We don't download all the assets used every time we load a page.

Actually we do download most of them. Browser caches are mostly useless for most of the stuff, including widely use JS frameworks and fonts. There were a few widely circulated articles on this.

ok, but the article says that there is more images (btw, other media too), i.e. images make 50% of web page now and image size growth contibutes ~400KB out of ~900KB, images tend to change, given that top 1000 pages are dynamic, thus, no cache will help. Also I find it interesting that stylesheets are growing, given that css3 are more powerful now and IE6 is likely to be retired for most of these sites. What is interesting is what makes this "other" part? is it just webfonts or some media (also very cross-site cache friendly)?

Image size could include things for retina displays, higher standard resolutions, CSS sprites and so on. Again though, a lot of images in sites are standard reusable assets that are held in the browser cache between visits - it's just editorial and user-contributed content that won't get much benefit from a well configured http server.

Sidenote: I found out about kraken.io on HN a while ago. I use it for all my images now. Usually gets at least 5% reduction on a well created picture, and 50%+ on a bad one. (No affiliate, just like it)

I don't think that CSS sprites should be bigger, given that css is improving, I don't know about the sample analysed, but usually the editorial and user-contributed content images (as well as ads) take much more bandwidth than style related images, unless the site has exotic design. aside: kranken.io is nice

99 http requests still take some time even if the response is 304.

That's not how you cache. You shouldn't have any 304s for images, js or CSS. If you are, your setup is wrong.

Mark minified js & CSS with a file hash in the path or query string & serve a far future expires header. Browser won't even 304 it and serve straight from local cache.