Ajax can *Improve* Performance Too

Recent Ajax apps like Kiko are sluggish according to Alexander Kirk’s “Rise of Slow Ajax Applications (via AjaxDeveloper):

Pages get more voluminous because so much code has to be loaded to the browser (which makes the browser slow again) so you could just begin to use the application. This somehow reminds me of all the flash apps. Waiting for hours to load the page and you’ll stick to that page for half a minute.

The initial delay is due to loading of Javascript and data too. Fast startup is certainly a big motivation for Ajax, so it’s a problem if that’s not happening.

Alexander gives four tips:

  • Keep it bookmarkable. Don’t load everything to one page, let users return to a certain section of your app via their bookmarks.

This is sort of mixing two concepts together. Using Unique URLs, it’s possible for an Ajax app to be bookmarkable, but still the same “page”. I think the advice here is to use real page refreshes rather than making an entire website a single Ajax application. I think that’s fair for a big corporate website, but for a standalone app like Kiko, it’s best seen as a last resort. Saying that, a reasonable use might be in switching between a general login/menu page and the core app itself. Or, in Writely, switching between the different tabs – editing, blog it, etc.

  • Don’t overuse AJAX. Often simple Javascript without server interaction will do. Try to reduce the server callbacks.

Agree with the tip, though not necessarily the implicit definition that Ajax == server interaction. Rich, standards-based, Javascript is Ajax in my book, and certainly a good way to improve performance.

  • Minimize the code to be loaded. When you don’t have any other choice, consider code downloading.

Code downloading – or On-Demand Javascript – is actually quite easy to do. It involves loading some basic Javascript immediately and continue to load the rest in the background or as needed. You can load the JS by tweaking the head element, or alternatively by pulling it down with XMLHttpRequest and eval’ing it. As an extension of multi-stage code loading, there’s also Multi-Stage Download – downloading an initial structure upfront and populating it with further calls.

  • Speed up your apps with AJAX. Use AJAX for what it was meant for: tune your existing application at points where postbacks need to reload the same page with only little change.

Great point. <rant>Too often, Ajax is blamed for making the web slow, unaccessible, unusable, etc. But what if we stop a minute and ask “What if Ajax could improve performance/accessibility/usability? How could that happen?” By attempting to answer these questions as effectively as possible, even if we disagree with the premise, we’re better equipped to weigh both sides of the argument.</rant>

In the case of performance, there are plenty of ways Ajax actually improves the situation. For starters, you don’t need to download an entire HTML page every time you talk to the server. More specifically, smart Javascript can do stuff like caching, guesstimating, and pre-fetching.

7 thoughts on Ajax can *Improve* Performance Too

  1. I’m surprised by your title.

    XmlHttpRequest is a great way of improving performance, as you don’t need to transfer the whole page over the wire, you only send update. The processing time on the client is nothing compared to the time over the wire, especially when connecting to the other side of the world.

  2. Julien, the title was like that because I’ve seen a few people question whether Ajax performance is scaleable, ie Google can do it, but can everyone else? I think it’s a fair question, and it’s a matter of designing things right.

    Also, latency is a critcal issue for functinoality like Suggest/Auto-Complete.

  3. First of all, thanks for your comments.

    I don’t completely agree with your point on Unique URLs. Your rewording hits the point I wanted to express. I don’t see different rules for Kiko, though.

    The technique using hashes is a bit too complicated when the solution is just as apparent as to reload the document (thanks to caching it should be possible to have that reasonably fast).

    For example in Kiko each day in the calendar should have it’s own URL. I would want to bookmark that, or send the link to someone else. The “Kiko loading” sign appears anyway with that — why not change the URL after all.

    For states as an open tab on a page, I think using a hash is an appropriate solution that does not throw away the original intention of hashes (put me at a special spot on one page).

    I still think that major changes — also in web apps like Kiko — should still do a page reload. This also reduces the memory eating of browsers.

    I’ve also shown my technique of code downloading in my blog. What I like about this technique is that you are actually in control over the sequence of loading (specifying many -tags you leave the decision up to the browser) so you can overwrite code with new one. By using this you can have a specific execution pattern for every state of your page.

    Concluding, I would like to say that it is an important point not to throw away every concept we have had so far but extending it with AJAX. For compatibility and standardization reasons.

  4. Alexander, it’s a fair argument that Kiko could have a different URL – and a real, non-hashed, one at that – for each day/week/month. Performance-wise, it’s certainly a bigger download that way, but perhaps not too bad, esp with all the JS cached. And assuming latency is the real issue, the extra download isn’t too much of a burden.

    At the same time, the flushing of memory is a two-sided coin. Yes, it prevents leaks. But it also creates more programming overhead. Suddenly, all the little session things, like recent history, have to be uploaded and then downloaded again. I know that’s not overly difficult, but it does prevent the browser app from being truly rich if the programmer has to worry about synchronising state for everything.

    Also, it depends what the full URL will return. Ideally from a performance perspective, the entire HTML as it needs to be shown to the user. But that’s more difficult to program, because the browser side must also be capable of doing something similar. If it’s just a barebones HTML page and some JS then loaded on-demand, how much has been achieved over a pure DHTML page swap?

  5. Michael, You’ve got some points on your side.

    My main point is that URLs should stay as “talking” as they have become. A few years ago everything dynamic had an ID in its url. Thanks to URL rewriting (and other techniques) this has changed. We should now not start mis-using URLs again, just to prevent a reload.

    IMO manipulating the DOM too much isn’t a good idea anyway (also from a programmers perspective, it can be very tricky to track properly). To stick with the Kiko example, when loading a calendar for a specific day the interface HTML data could reside on the server with filled in calendar entries. The fragments that would have been loaded via Javascript can be accessed faster from within the server anyway.

    A major state change (which deserves a new URL in my eyes) in form of a reload might implicitly also solve usability issues to show the user that something big changed as the whole page reloaded.

    I’m not so sure whether we should try to extinct the “web” flavour from web pages. We’re still in a browser window at the moment.

    Btw: could you enlarge the comment-textarea a bit, please? 🙂

  6. Pingback: alexander kirk » Blog Archive » Better code downloading with AJAX

  7. Pingback: alexander kirk » Blog Archive » Better code downloading with AJAX

Leave a Reply to Alexander Kirk Cancel reply