mnot’s blog

Design depends largely on constraints.” — Charles Eames

Sunday, 19 June 2011

Caching HTTP Web

Fixing AppCache

HTML5’s AppCache mechanism is one confused little puppy. Purporting to be for taking web applications offline — a compelling and useful thing — it’s more often used by performance-hungry sites that want to use it as an online cache.

Unfortunately, this means that those sites will be popping up dialogues like this:


Even more unfortunately, if you click “Don’t Allow”, you’ll just be asked to approve it again next time you navigate to the site.

And again. And again.

I’ve heard lots of developers complain about AppCache, and I suspect it’s because, in the words of Marlo, they want it to be one way, but it’s the other way.

Making AppCache Cache Apps

For AppCache to do what it purports to do, it needs to be initiated by the user, rather than by the site. The trigger for getting some extra disk space and special treatment should be user interaction (roughly, a “take this application offline” or “add to my app gallery” button), along with some metadata about what that means (the manifest, etc.). Having random Web sites pop up modal dialogues simultaneously sucks and blows.

That implies that offline apps need some special status; something like Chrome’s “apps” listing, or an icon on a launch screen, but without the need to list it in a browser-specific “ store” (a repulsive grab for control of the Web, a la Apple’s AppStore, if I ever saw one). You should be able to install from any Web site, not just one ordained by your browser vendor.

Making Browser Caches Cache the Web

That’s not going to happen until browser vendors supply a viable online cache for those performance junkies, so they don’t feel the need to abuse AppCache.

There are lots of things that need improvement in browser caches (in my experience, deploying a single-user local Squid has a HUGE performance impact, both because of better caching and better connection management, although perhaps Firefox 5 will address the latter).

However, for the purposes of this discussion, AppCache does two things that are attractive to your garden variety performance nut; it makes a dependable slice of space available, and it allows you to prefetch things into it.

Prefetching is easy; Mozilla already supports the “prefetch” link relation, and other browsers should too (some are working on it, as there are some subtleties to it).

Giving a site a guaranteed slice of the cache (called “cache pinning” in the old days of Web caching) is a bit tricker, but doable. I’d start by suggesting that bookmark/favourite’d sites get an automatic slice (say, 10M), while a site that’s been visited recently (i.e., one of the last N sites surfed) gets a smaller slice (say, 2M).

Then, give sites control over their preferentially-cached content by offering refined Cache-Control directives, so that (for example) a video on the site doesn’t blow the rest of the cache away.

This approach means that when your cache becomes too big, the least recent site is evicted, rather than the least recent resource. That gives sites a much more dependable behaviour; they’re either in-cache (to the degree determined by the cache bucket size) or not, governed by the user’s behaviour towards the site plus their own freshness policies. Contrast that with a straight LRU or even the relatively exotic Greedy Dual-Size; while these are great eviction algorithms for a shared cache, they don’t make as much sense for single-user caches.

That’s just a straw-man, of course. The important thing is that we need to start a dialogue about fixing browser caching, rather than abusing something not designed for it into the role. Who’s up for it?

I’ll note here that nowhere have I suggested that HTML5’s definition of AppCache needs changing (beyond, perhaps, some judicious UI advice); while I do think we could have defined it in a way that fix in better with Web caching better (especially that HTTP caching already supports disconnected operation), it’s too late for that, and we all have better things to do than get into religious wars about style. See Mike Kelly’s blog for an alternate view.

I also think that AppCache needs to be extended quite a bit to be really useful for offline (e.g., with fallback representations for failed interactions, queues for outgoing updates, etc.), but I can understand why HTML5 doesn’t want to go the whole hog in one go.


Mike West said:

Hi Mark,

I enjoyed reading your thoughts about appcache. I think some of the things you’re talking about mesh well with some ongoing work in Chrome (we’re in the process of building out and exposing the internal quota system to users), and I’m going to forward it on to the relevant groups. I think the concepts go well beyond appcache in itself, and apply to pretty much any of the temporary local storage APIs that websites have access to (I’m thinking specifically of the filesystem API, but the various database types fit too). If I’m understanding you correctly, then we’re very much on the same page with regard to eviction: when the quota is hit, the least recently used origin is removed in its entirety. We don’t currently differentiate between the types of non-persistent storage, but I think the idea of giving a bookmarked website a bit more quota than others is a good one.

On a different topic, and with the disclaimer that Google pays my salary, that I’m on the Chrome developer relations team, etc, I’d like to quickly address the remark about the Chrome web store (“a repulsive grab for control of the Web, a la Apple’s AppStore, if I ever saw one”) with two responses:

I think we’re generally pretty careful to talk with developers about web apps, not Chrome apps. I’m happiest when apps work across all modern browsers, period. While the apps themselves generally aren’t Chrome specific, you’re correct to say that “installing” applications into a browser is, at the moment, browser specific There’s no technical reason it has to be that way; all the docs, formats, and protocols that the store uses are documented and open.

There’s work ongoing (behind the “CRX-less Web Apps” flag) to allow users to grant certain websites special status without going through the store. It’s not ready yet, on a number of levels, but it’s a good indicator of the direction the team is working on.



Sunday, June 19 2011 at 6:34 AM

karl dubost said:

Mark, you might be interested by the thread starting in June and continuing in July about AppCache. Someone is asking for a PageStorage feature.

Thursday, July 7 2011 at 8:53 AM