On UpdatePanel Performance

Phil Winstanley (Plip) tried to leave the following comment relating to my blog post about UpdatePanel performance but found that you had to login to leave comments so he mailed it to me instead. I wasn't aware you had to login to leave comments (shame on me) and I think I've now fixed this (but frankly the blog settings I see on my blog dashboard don't bear much resemblance to the behaviour of my blog so it's a bit hit and miss!). Anyway - Phil's comment in its entirety:

"While what you say here is strictly true it’s not always the case, not only that, but there are other considerations to take into account when using the update panel. The main thing is, people find it easier to use so click it more than they used to, it’s a different mindset (I’ve seen this with log files in IIS – people are behaving differently).

Look at how you use your mapping application of choice, you put very little consideration on scrolling around the map, whereas with something like streetmap where you have to press the button to go up, down, left or right it’s much more important that you think before clicking.

The update panel has been massively improved on performance, it used to be utter crap, at one time every request for every panel brought down the <head> content of the page (imagine all that meta data!), this has now been changed to fragments so that only the relevant sections are updated: -

|54|asyncPostBackControlIDs||ctl00$MainContent$SearchVehicles1$SearchVehiclesButton|0|postBackControlIDs|||54|updatePanelIDs||tctl00$MainContent$SearchVehicles1$VehiclesUpdatePanel|0|childUpdatePanelIDs|||53|panelsToRefreshIDs||ctl00$MainContent$SearchVehicles1$VehiclesUpdatePanel|2|asyncPostBackTimeout||90|12|formAction||Default.aspx|8 |pageTitle||Tracking|

Now, I am starting to see complaints from people on slower lines that it takes a “long time to load” which it doesn’t, it takes less time than without an update panel but the perception they have is that the rest of the page is there instantly (never changes) so why is the section they’re working with not there straight away, “what’s with this spinning logo?”.

People are so used to the “click ... wait ... white screen ... wait ... page loads ... images load ... ready” that they’re finding Ajaxy stuff a real mind shift, it’s confusing some and others are claiming websites are “broken” because it’s not behaving the way they’re used to.

I wish performance were just about numbers J

Oh and don’t use Fiddler, use HttpWatch, much slicker: http://www.httpwatch.com/"

And I can't find anything to disagree with in that (apart from the comment about HttpWatch as I've never used it I have no idea if it's slicker but I'm going to give it a try). What I was trying to say in the post was; if you're looking for ways to reduce traffic then judicious use of the UpdatePanel can bring benefits. Don't immediately discount it in the search for "optimum performance" simply because it's so easy to use (as I did in the conversation at the MSDN event yesterday). Phil makes very valid points about perceived performance and that's another consideration you need to be aware of. You might think reducing your network traffic will solve a problem but it might well introduce another more subtle one.

[Update: I should have mentioned that I published Phil's comments with his permission]

Technorati tags: asp.net, ajax, updatepanel