Request Reduction - The Cool, but Clunky Method

Yesterday we saw an interesting effort from Digg to address the problem of multiple requests and its effect on page speed.

Recently there has been growing interest in various schemes for request bundling. For example, a way to use data URIs in most browsers was shown here: http://www.hedgerwow.com/360/dhtml/base64-image/code.txt. It is ugly, but mostly works. In the past we have seen other folks use a variety of client and server-side schemes to bring inlined images and other assets to the masses - mostly with little success. That’s too bad.

These are great efforts and request bundling is the proper solution for ultimately addressing speed problems as you go beyond Gzip, Caching, and other commonly known methods. For most higher bandwidth users it is the number of requests not byte count that is killing their performance.

We like ingenuity here but honestly Digg’s effort is well… a hack and a half. We can safely say that it is going to blow up for a number of reasons we are directly aware of, so we’ll enumerate.

Data URIs Close But Yet So Far

The Digg scheme relies on parsing the incoming multipart stream and creating data URIs (http://en.wikipedia.org/wiki/Data_URI_scheme) out of it. Older Internet Explorer browsers do not support data URIs. You can try to hack you way around this, as recently shown, using object and MHTML to stuff things in, but testing is showing that approach to be problematic. Even with IE8, which supports dataURIs, you have significant length limitations - 32K for in-page objects and far less for raw URLs.

Multipart Support in Ajax - Rare and Inconsistent

Multiparts with XHRs are not at all consistently supported across browsers. Test it yourself and you’ll see what we mean. Even amongst the supporting ones you are going to get quirks. This is discussed in our CEO’s Ajax book, chapter 3. Worse yet if you are trying to deal with partial streams as you go along; that is also a black art and problematic, particularly in Internet Explorer. The comments in Digg’s code reveal they are discovering that the XHR object varies from version to version in IE. It isn’t commonly known, but the XMLHttpRequest object is actually pretty inconsistent in its details from browser to browser and version to version.

Cachability

A huge problem with many Ajax solutions is caching. It is possible in principle to work with the browser cache or better yet even add an Ajax cache. But most Ajax performance schemes like Digg’s fail in practice because the end user cache is not populated properly–unless you plan on using the dataURIs as the cached item everywhere else, which is pretty unlikely. In order to still use the cache, these implementations must often fire off subsequent requests even after the first page load to populate it.

Right Idea - Wrong Solution

To be clear, we think that an initial, bundled request of dependent assets is a GREAT idea. However, it has been a great idea for years and many of us have tried to do it, but the challenge is all in the execution. This way of doing it is not the right way… at least for the long haul.

Ultimately, the major browser vendors (i.e. Internet Explorer, Firefox, Chrome) need to facilitate this type of performance optimization, by creating a JAR file, bundle, archive, or something, so we can negotiate a large initial request and have our proper caching too. We just can’t be dependent on JavaScript for page composing duties if we want top-notch performance. Even with the massive improvements in JavaScript speed via browser engines like Google’s V8, WebKit’s SquirrelFish, and Firefox’s Tracemonkey, any JavaScript page composing is going to be smoked by a native solution. JavaScript is a great development environment for Web 2.0, RIA type applications. But fixing browser plumbing with JavaScript is just not the way to go for permanent performance gains.

We’ll be happy to be wrong, but having seen this before we kind of doubt it. This is in fact worn ground: Delta encoding with JavaScript was tried well over 8 years ago and it just isn’t something that reliably works in scale.

The good news is that the native browser changes in this area are coming–just wait! We are about to show one that is relatively newly shipping.

- P80

Note: We should note that Digg’s interest in trying to control page paint order is quite appropriate, since the perception of speed comes not just from downloading but how the page paints.

{follow us on Twitter @port80software}