Digg's New DUI.Stream and MXHR

http://blog.digg.com/?p=621

by snewe • 17 years ago

43 24 17 years ago

blog.digg.com

aston2• 17 years ago

Interesting idea, attempting to crunch all of the requests for a page snippet into a single request. Why do it in Javascript, though?

It seems like you'd be better off with a pre-processor server-side to inline include CSS, Javascript and images, then send the resulting page back for rendering. Javascript isn't nearly as fast as my C++-based templating engine...

edit to add: Also, don't discount the big savings you can get from "302 Not Modified" return statuses, especially on big chunks of content like images. The DUI.Stream image demo they had would get smoked by the 'dumb' version if they allowed the browser to cache the digg dude.

thamer• 17 years ago

I suspect there's not much to gain by caching images in the browser: If you're looking at a page full of comments with hundreds of avatars, chances are the next page is going to make you load hundreds more that you haven't seen already: There is a very large number of commenters, and you probably won't see the same people on every page.

The demo is right: they ask for 300 different images (as in, different URLs), and their packager makes it faster.

Also, how would you inline include images? Using base 64 in the image tag?

aston2• 17 years ago

The demo is pretty unfair. If you want to package lots of the same image, you just use it and let cache control do its job. If you want to package lots of different images, you should use a big sprite (again, server-side packaging without any js). If you want to make image loading look slow, do what they did in the demo.

cakeface• 17 years ago

There are a bunch of images that can get repeated across pages for a web site that are completely vital to cache. Think rounded corner images or background images or icons.

ncrovatti• 17 years ago

Lazy loading seems more efficient to me for this particular use.

ojbyrne• 17 years ago

They do plenty to cache images (including the digg dude). This is about the first load. Yahoo has some report showing that data is uncached quite a bit of the time, even when sending the appropriate headers.

vdm• 17 years ago

Hmm, this goes some way to making up for the diggbar.

schtono• 17 years ago

Did you figure out how they're transforming the serialized image data into real images? I remember there was something like a data-attribute in the img-tag back in the days, but i thought it was deprecated years ago...?

Any hints?

Glide3• 17 years ago

They have an object tag with base64 encoded images.

a-priori• 17 years ago

It looks like they do it by replacing the image tags in the DOM with an object tag pointing to a "data:" uri containing the Base64-encoded image data. Here's two pieces of relevant code, first where they fire off the listeners for the DOM objects, and second where they replace the DOM objects:

http://github.com/digg/stream/blob/66dcce320c73b109cd5836e44...

http://github.com/digg/stream/blob/23a411eb0cc00048bbb090889...

Glide3• 17 years ago

I don't think they're replacing any objects.

Every time a Content-Type of image/gif is encountered it appends a new object to #stream with the image data inlined. I was really confused at the object tags at first, so I went ahead and copy pasted one of the object tags with image data into a blank html and loaded it into firefox. The image showed up fine.

This is an extremely clever solution. I know jQuery UI's icons are in one giant image file and background offsets are used to display the correct icon, but this is probably better for a dynamic solution because the amount of CPU it would take to stitch upwards of 100 images together.

tjpick2• 17 years ago

what advantage does this have over using something like keep-alive? http://httpd.apache.org/docs/1.3/keepalive.html

Keep alive, to me, seems better as you don't have to modify the frontend architecture. Turn it on at the server and let the server and browser do the hard work.

zemaj2• 17 years ago

Keep alive maintains a persistent connection, you are still limited by the number of concurrent connections to the server and the latency that each one experiences.

MHXR bundles all your requests into one. This leads to savings the latency overhead on each request (& probably some server resources not having to deal with multiple connections too).

I tell you what; piping binary data into objects? Genius! I had no idea that was possible.

tjpick2• 17 years ago

yeah, my understanding was that the overhead of a request is significantly less than the overhead of establishing a connection. So by using keepalive/persistent connections, you get the majority of the savings. All the headers and data for each file still have to get sent over the wire in the digg solution anyway, and the concurrent connections limit is the same in both cases.

But thanks for explaining, I see the latency particularly is an issue.

timdorr• 17 years ago

Even better: HTTP pipelining - http://en.wikipedia.org/wiki/HTTP_pipelining

Of course, that's controlled client-side and often doesn't request all that many resources at once. This is a server-side pipelining that lets them determine their own capacity (which makes sense).

Of course, I'm not really sure how they're going to do this in IE, since it doesn't support decoding base64 content to image data on the page. Something tells me this is going to hit a bit of a brick wall.

zemaj2• 17 years ago

Pipelining does not work in most browsers (& is disabled in FF by default). When it does work it can be flaky. A JS solution works on current technologies.

mr_justin2• 17 years ago

Unless I'm reading their demo wrong, their technique makes the page load slower (for me anyway): http://demos.digg.com/stream/streamDemo.html

Normal is consistently under 100ms and MXHR is around 400ms (using Safari 4 beta, OS X)

thorax• 17 years ago

In all of the browsers I tried (FF3, IE8, Chrome), the timer gave me 4x slower using the MXHR stream on first try. But when I refreshed it was always wildly faster for the MXHR side (and still substantially faster on cache refresh).

mitchellh2• 17 years ago

I get the same thing with the text version. I refreshed 20 times and only got 1 that was faster (and only 7ms to boot).

But if you try this in a non-IE browser: http://demos.digg.com/stream/imageDemo.html

The image demo performs amazingly well! I wish there was a timer for that one but its extremely fast.

mitchellh2• 17 years ago

CORRECTION TO THIS BY AUTHOR: There is a timer, it just waits until all the normal images load (and I was too lazy to wait). Upon refreshing, the MXHR stream was 10.3x faster on my FF.

mikeytown2• 17 years ago

Use this trick instead of CSS sprites.

Digg's New DUI.Stream and MXHR

Related Stories