Bandwidth savings with AJAX

MacRumors has released the results of their experiment using AJAX to deliver presentation updates from MacWorld. The numbers are simply jaw-dropping, a 6X reduction in bandwidth.
“[We] consumed over 32 GB of bandwidth during the three hours surrounding the event. (For those interested, a non-AJAX version of MacRumorsLive would have required an estimated 196 GB of bandwidth over the same period of time)”
For sites that experience a highly variable load, AJAX can mean fewer servers, lower bandwidth bills, and less risk of failure. This is a huge, public win for AJAX as a bandwidth optimization strategy.

The old-school RIA technology vendors always made the claim that using the RIA paradigm saves you bandwidth. Numbers on this were always hard to get, and hard to trust.
Theoretically it always made sense that an RIA would consume less bandwidth (in exchange for a larger initial download). The longer a user continues to use the application, the greater this benefit (so an RIA word processor might make more sense than an RIA news site).
Now, watching a keynote presentation takes at least an hour, so it’s definitely long enough to provide benefit. What we see in this case is really different though: AJAX is basically being used as a broadcast technique, grabbing new data every minute so that the user doesn’t have to refresh the entire page. For covering live events that have a large audience, this makes a ton of sense. Expect to see more content sites “pushing” content out to their users this way.

6 thoughts on “Bandwidth savings with AJAX

  1. Blaine January 13, 2006 / 9:21 am

    The only problem I have with it is the 19gb number…
    I used their RIA for up to the minute news and it was great – but if I was going to use the “old way”, i wouldnt’ve been refreshing every minute… taking up less bandwidth…
    I believe there’s a savings, but I’m not too sure it’s THAT much of a saving…

  2. John Dowdell January 13, 2006 / 9:47 am

    There’s another variable here, besides “page-refresh vs data-refresh”, and that’s the automatic polling… if the JavaScript checks back with the server every minute then that may be a different rate at which someone would manually refresh a full page in their browser.
    … hmm, maybe there’s a further variable too, depending on how the XML was structured, and whether deltas were appended to the last local text delivery, or whether the full text was transmitted in XML form every minute….
    I’m not sure that their billing of it as “AJaX” is warranted — seems like it’d be more accurate to say that they separated the text from all the JavaScript, all the styling information, all the layout HTML information — the use of an XmlHttpRequest call seems more an incidental implementation detail, compared to the overall decision to rearchitect the document so that the content is finally separate from its presentation…?

  3. John Dowdell January 14, 2006 / 12:39 am

    Hi Jonathan, I picked you up over at my place, but this is where it started…. 😉
    After you pointed out that technique used for that job, it was hard to stop thinking about it… if you, yourself, had to cover a linear news story like that, then what are the pro-and-con angles of different ways of doing it?
    Regular user-triggered, full-page refreshes still work great. If your server spikes that’s bad, though. But if the full page is delivered quickly, then ads can be rotated, which is a big plus on many projects. Classic HTTP is great.
    I still use dialup sometimes, though, so I can see things others may not. Lots of popular classic-HTTP pages are dog slow, usually from multiple calls out to third-party sites. No fancy stuff but all the HTTP requests take ages to sequence and load. (Online/paper newspapers, for instance… lots of those sites call out to many affiliates.) For breaking news, just refreshing the data and keeping the display & logic clientside may work better.
    But is text the best media to use?I’m not sure. If Steve Jobs is giving a speech, why not just go for straight audio of the speech? One reason: I might not want to hear every word in realtime… text can abstract ideas (even as different writers inevitably color those ideas). Good text is more accessible than straight audio for those whose time is constrained.
    Hmm, a lot would depend on my own physical experience at the time, whether I was hanging onto every word or whether I was catching up on news later in the day… the media choices seem like they’d vary with the audience….
    … whew. Good thing I don’t have to work that project, I guess, I’d overthink it to death…. 😉

  4. Jon January 14, 2006 / 1:08 pm

    My guess is that your boss would tell you “we’re a little mac fan club site with no revenue and two servers. There’s no f&*king way we can support streaming audio for a billion people”. And then you would implement the text solution, just like they did. ;->
    I’ve also seen the extra latency caused by calls out to third party sites (mostly because I have javascript that waits for the page to load to make that AJAX accordion on my right pane visible).
    Google is a big offender…I took their adds off my front page because they were slowing everything down.

  5. Jesper Rønn-Jensen January 16, 2006 / 3:06 pm

    Very interesting point you’re making about traditional RIA and bandwith saving. It’s really interesting to see when the technical considerations and usability considerations converge — which i tried to cover in a recent blog post at AJAX performance stats, ROI, and business value

  6. Jon January 16, 2006 / 11:08 pm

    What a great article! I’ve been meaning for months to do an AJAX ROI piece of some kind, but I’m so deep in the technology that moving my brain “up a level” to the business case can be hard.
    Keep up the good work…I found that article and the articles you link to within it quite insightful.
    I for one am skeptical that the main value of AJAX is bandwidth savings. I think that the bandwidth that is saved should probably be consumed in the name of a richer, more interactive / seductive (for ecommerce) or powerful (for business apps). Frankly, most companies don’t have the kind of crazy traffic that warrents thinking about the problem that way.
    One mans opinion! Anyway, thanks for stopping by.

Comments are closed.