WebTopics

IIS and ASP.NET Information and Tips from Microsoft Developer Support

Fix: UpdatePanel Async Postbacks Slow in Internet Explorer

Fix: UpdatePanel Async Postbacks Slow in Internet Explorer

Rate This
  • Comments 29

We've seen a few issues recently where customers were experiencing very slow async postbacks via an UpdatePanel, but only in Internet Explorer. Other browsers worked fine. (When I say "very slow", I mean in the neighborhood of 30 seconds!) The cause for this isn't a mystery to us.

Because of the way our HTML viewer (mshtml.dll) was designed, Internet Explorer is slow to iterate through large DOM collections. As it happens, the PageRequestManager class has a method called _destroyTree that does just that. It uses a for loop to iterate through all of the DOM nodes in the UpdatePanel's DIV. It does this on the client (the browser) before the request to the Web server is ever kicked off, and if you have a large DOM in your UpdatePanel, you might see a very long delay in Internet Explorer when this occurs.

If you're experiencing this kind of problem, I have good news. We've fixed this for the next version of ASP.NET, and we also have some code that you can use in your applications now to mediate the problem. You can find the updated code in our Knowledge Base at http://support.microsoft.com/?kbid=2000262.

Update 9/29/2009:
Removed the code from this blog post and referenced KB instead. We did this so that we can service the KB article without having to update this post in the future.

 

Leave a Comment
  • Please add 3 and 6 and type the answer here:
  • Post
  • Hey,

    The code is broken.

    Opening curly brace of function body is missing and it gives JS error on the page.

    Looking forward for the proper code.

    Thanks in advance.

    Regards,

  • Sorry about that, Velio. Must have been a stray keystroke when I transferred it over. I've fixed it.

    Jim

  • Great job and tremendous piece of code, Jim.

    Initial usage and tests shows fantastic improvements on UpdatePanel performance.

    Regards

  • Thanks, Velio. The credit goes to our product group. I appreciate the update.

    Jim

  • This is really great. Yes it save a lot of loading page in update panel. Thank you very much

  • This is fantastic, my web page works like a dream now.  

    I have been delaying a release of a whole batch of changes due to slow postbacks and you have just saved me from rewriting the whole page using webservices and other time consuming developments.  Great stuff.

  • I am getting a js error 'nodetype' is null or not an object. Any thoughts?

  • Peter,

    Do you have a URL or can you share your page?

    Jim

  • No I do not. I did see that you had updated code in your Knowledge Base article and changed it. That fixed the error but my update panels seem even slower. I am not even hitting a DB or anything. Just updating labels with user selections in a form, kind of a summary of what was selected. We use IE6 as this company has not even updated to IE7 yet. Although it is slow in IE7 and 8 as well. Probably just my code. It is instantaneous on my development machine. I was surprised at how slow it is on the live server. It kind of makes it useless now. Oh well, live and learn.

  • Couple of things, Peter. First of all, if the code is entered correctly, you shouldn't get an error whether you're using the latest updated code or the previous code. All I can guess is that there must have been a typo.

    If you are still experiencing slowness, it's not caused by this issue. If you want assistance in tracking it down, you can open a support incident with us and we can help.

    Jim

  • Well Jim,

    I triple checked the code and kept getting the error. It obviously did not like something in the page. There was no typo, but thanks for assuming I am an idiot. The latest version does not throw the error. I do agree that something else is causing the slowness. I am afraid I cannot share any code with you to help fix this problem. Thanks for the offer. And it was a good idea to remove the code from here if it was not being updated.

  • Sorry you took it that way, Peter. I certainly wasn't assuming you were an idiot. Because the code was tested thoroughly and is in use by many people without any errors, I surmised that you might have a typo. I would never say someone is an idiot for having a typo! I've had pelnty of them myself. :) Everyone does.

    We are updating the code if we can improve on it, but we wanted to make sure to have it in only one place so that it didn't have to be updated twice. The code is available in the KB article linked on this post.

    Jim

  • I really did not take it that way, just my dry humor I guess. I'm just really bummed that it did not help me. I showed the boss the functionality on my machine (where it is super fast) and he loved it. Now it is pretty much useless on the live version until I speed it up. I'll keep checking for updates though. Thanks.

  • Understood, Peter. Funny thing is that when I originally posted this blog entry, I had a typo in the code. :)

    Yeah, this code is designed to work around a very specific issue. If you don't see slowness in Firefox, that's an indicator that it may be this issue.

    We have a lot of skill in troubleshooting performance issues like yours, so if you reach a dead end, open a case and we can help out!

    Jim

  • It is very crucial to put the JavaScript "immediately before the closing </body> element". In other cases it may not work.

    Thanks for the fix!

Page 1 of 2 (29 items) 12