An Ounce of Prevention
We’re all for new approaches to accelerating the web, and Google has been doing lots of interesting research for quite a few years now. Google’s latest approach, QUIC (Quick UDP Internet Connections), is documented in a great piece over at Ars Technica.
But, as with virtually every approach to the problem of how to make the web faster, Google’s new approach is guilty of ignoring Benjamin Franklin’s famous aphorism,
“An ounce of prevention is worth a pound of cure.”
In the context of speeding up the web, this means that what Google – and every WAN optimization vendor – is doing is curing the problem of optimizing delivery of web pages. Their approach is to say, “Okay, the browser is requesting something from the web server, so let’s optimize the transmission of that content back to the browser.”
In contrast, we advocate the prevention of the delivery of web pages, or at least, the needless redelivery of pages and their contents. Browsers are guilty of requesting needless redelivery because their caches have two glaring flaws:
- They are ridiculously small. Typical browsers caches today are a meager 250MB (and much smaller on mobile devices). That makes no sense in a world where the average laptop ships today with 500GB of storage (and where, in the corporate environment, only 60GB are occupied by the OS and applications), and where the average web page now exceeds 1MB.
- They are shared across all websites and web apps that a user visits, with no distinction between important and unimportant sites.
I’ve never met Mark Nottingham, but he’s been thinking along the same lines as us:
“I think that browsers should have an identifiable, separate cache context for each Web site that is visited, so that they can be independently limited, configured and interacted with.”
By letting users and/or admins allocate a dedicated cache to every site important to the user; letting the caches be substantial in size (the default in Mobolize CacheFront is 500MB per cache); and by letting every user have her own personalized set of caches, cache hit rates jump from about 40% (using the browser’s built-in cache), to 70%-95% using CacheFront, depending on the site. (We usually quote 80% as a typical average.)
In short, bigger, more useful caches let the browser fetch much more content from cache, preventing the round-trip from occurring in the first place. We think Ben would have approved.