Perhaps due to its ubiquitous presence in web based email services, implementing asynchronous site navigation is frequently a design requirement when building AJAX based sites. Unfortunately, the also ubiquitous UpdatePanel is chosen to accomplish this far too often.

I’d like to take a moment to strongly recommend against doing that.

I’m going to explain what I believe are the three most dangerous drawbacks inherent to UpdatePanel based navigation: Performance degradation, usability concerns, and lack of maintainability.

Note: I would add SEO concerns to the list of drawbacks, but I’m going to assume that anyone who cares about SEO knows better than to use an UpdatePanel for content they wish to be indexed.

Performance degradation (read: obliteration)

As I’ve mentioned in the past, UpdatePanels endanger the performance of your application. While the UpdatePanel does have its place, the underpinning for your entire site’s navigation system is not one of those places. A quick comparison makes this clear.

This is what happens when you use a LinkButton to trigger an UpdatePanel refresh:

• The PageRequestManager catches the event on the client side and runs through its pre-request events, while preparing an XmlHttpRequest object.
• This XHR object makes an HTTP POST request to the server. This request includes every form field on the page, including the entire ViewState (even for areas of the page not being updated).
• ASP.NET creates a new instance of the Page class, using the ViewState and other POST data to restore its state to that of your last postback or partial postback.
• The Page runs through its lifecycle and returns its rendered HTML result to the ASP.NET AJAX framework.
• The ASP.NET AJAX framework parses out the specific HTML section(s) that will be sent back to refresh the UpdatePanel(s) affected by the partial postback.
• This response is combined with other control information, such as JavaScript content registered via the ScriptManager’s various methods, and sent back to the XHR object.
• The PageRequestManger parses the response and updates the DOM to refresh the affected UpdatePanel(s).
• Finally, the browser renders the updated DOM.

Using a traditional HTML <a> link to navigate the browser to a different page:

• The browser makes a simple HTTP GET request to the URL.
• ASP.NET creates a new instance of that Page.
• The Page runs through its lifecycle and returns its rendered HTML.
• The browser receives this HTML and renders it.

As you can see, these two methods of requesting an update are two very different animals. Not only is the partial postback pipeline far more complex, but some of the additional steps are potentially very expensive.

Perceived performance is usually more important than actual performance. The UpdatePanel is not going to bring this to the table.

When considering performance, it’s also important to keep in mind that what seems fast enough in a local development environment may be devastatingly slow when deployed. It is essential that you test your application’s performance over a WAN connection early and often.

Usability? What’s that?

When you choose to discard the browser’s navigation system for one of your own creation, you also discard usability benefits that you might not be aware of. Each individual browser provides progress indication and other subtle cues that your users have spent years becoming accustomed to. Replacing that with a foreign system is jarring and needlessly introduces an artificial learning curve.

Further, you suddenly make yourself responsible for providing accurate progress indication in every browser. When’s the last time you tested your UpdateProgress template on an iPhone? Yeah, me either.

Personally, I make heavy use of the DragAndGo add-on for regular browsing. When I come across a site that won’t allow me to toss its links into tabs this way, I typically won’t spend much of my time fighting with it.

Needless to say, the LinkButton’s __doPostBack href quickly sends me packing.

Who will you find to maintain it? Not me!

Your single, monolithic page will add tremendous maintenance overhead to your entire application. Worse still, many of the problems don’t present immediately, so it’s easy to start down this road and find yourself painted into a corner later.

For just a taste of what you could be in for, consider these potential pitfalls:

• Imagine if every time you made a modification to page A, you had to carefully avoid breaking pages B-Z and then regression test them all.
• Imagine when your designer(s) want to make changes to the site, but its HTML is locked inside this single page structure. That interaction tends to already be painful enough even with a traditional page structure. Complicating it further is going to be a non-starter in just about any organization.
• Imagine trying to work in a multi-developer environment at all.
  • If you’re using VSS or TFS for source control, one developer checking out for a minor edit would lock the rest of the team out of the entire presentation layer.
  • If you’re using something like SVN, nearly every change to the presentation layer would result in a merge operation, instead of a simple commit.

Once you start thinking about the potential maintenance issues, you can probably think of a dozen more on your own. I won’t belabor the point.

Conclusion

Hopefully, this laundry list of drawbacks will save you from making the mistake of using an UpdatePanel for site navigation. If not, I hope that it has at least raised your awareness about the problems that lie ahead, so that you may prepare for them now.

So how should you do it instead? Iframes. It’s that simple.