arrow205 Comments
  1. Justin
    Jul 11 - 10:11 am

    Great post. I knew I was avoiding ASP.Net AJAX for a reason. I have been using Mootools for this very reason. I only want the data I need!

    • Michael
      Jul 11 - 10:44 am

      Justin, take out the UpdatePanel of the ASP.NET AJAX and the library is still useful.

    • Dave Ward
      Jul 11 - 10:53 am

      Don’t get me wrong. I’m not trying to turn anyone away from ASP.NET AJAX. I think it’s a great framework if you’re developing on ASP.NET.

      I mainly want to illustrate the drawbacks associated with careless use of the UpdatePanel, which aren’t necessarily very obvious at first glance.

    • Sergio Pereira
      Jul 12 - 12:54 pm

      To add even more, don’t forget that the asynchronous postbacks via UpdatePanel allow you to access the properties of all the other controls, and even update them. In your example, if you wanted to change the color of the label or hide it using your C# code instead of javascript, you could. It’s all a trade off for convenience.

    • Stian
      Jul 23 - 2:08 am

      Nice post, I definitely agree… :-)
      This is the reason we first made Gaia; to make a real Hijax library that was as like ASP.NET itself to use and as efficient to use as possible.
      With Gaia you write NO javascript at all! And no Script Manager! And no changes to web.config!
      Check out the cool video that is on our landing page. ;-)


  2. Mike
    Jul 11 - 2:27 pm

    Nice post, but with this kind of title you might scare some people. An asynchronous postback with an UpdatePanel contains about the same amount of data than a normal postback, but it’s not ‘dangerous’ at all.

    Also, the second method will not update the ViewState, that is important too. If anything, I think it’s positive that ASP.NET Ajax allows you to go both ways.

    • Dave Ward
      Jul 11 - 4:45 pm

      You’re definitely right about that. A partial postback will always be more efficient than a full postback would have been to accomplish the same task.

  3. Rob
    Jul 12 - 5:30 am

    UpdatePanels aren’t dangerous, they just need to be used carefully and appropriately. They clearly don’t offer best on-the-wire performance compared to web methods/JSON but they’re better than doing an actual postback!

  4. Maxime
    Jul 12 - 9:49 am

    I think we can make an allusion here. Drinking one beer wont be fatal for you but drinking 25 of them in an hour would put you down. Here is why I brought that up… UpdatePanel need to be used carefully and this example is not a real life example but a minimalistic one (why even use AJAX here :P). On one of my project, I have a Wizard with a MultiView and I want the user to go through the registration process completely without any hassles. Going with the update panel take me an hour. Going with web methods, Javascript and JSON would take me a day without greatly improving the performance (and if it does by only a few bytes). Don’t misunderstand me, I don’t say that JSON and WebMethods are to be thrown… I just say that each have their own way to be used.

    Any comments ?

    • Dave Ward
      Jul 12 - 10:12 am

      Something like your example is a place where an UpdatePanel is well suited. I couldn’t agree more. If for no other reason than the fact that you need ViewState to make those controls work smoothly.

      I’ve been seeing more and more questions posted on the ASP.NET forums lately about how “AJAX slowed down my web page”, that usually result from someone deploying a heavy-on-the-wire app that runs great locally but bottlenecks over a WAN link. If they’d read a post like this before planning, they would have been able to avoid the problem completely.

      With that in mind, my purpose here is just to highlight the underlying dangers of careless UpdatePanel use, not to discourage use of UpdatePanels across the board.

      • Maxime
        Jul 12 - 10:22 am

        I totally agree with you. In fact… now application that ran smoothly in locals shall be converted directly to web.

        I saw example of people converting a DataGrid of a WinForm directly to a GridView without considering the size of the viewstate and the normally slower speed of a WAN network (talking about thousands of rows with multiple KB of data for each row being transfered). Those were obviously bad representation.

        However I would love to see a post from you about this kind of things that people are assuming and don’t think about.

        Cheers buddy.

    • Sumant
      Dec 21 - 5:39 am

      I definitely agree with him on this,because if you have tight deadlines you can waste putting alerts and debugging a script.

      • Dave Ward
        Dec 21 - 5:21 pm

        There’s no need to use alerts when you’re debugging JavaScript. Using a tool like Firebug or Chrome’s developer tools (and even IE9′s developer tools aren’t terrible) makes debugging JavaScript very similar to debugging server-side code. You can even debug JavaScript inside of Visual Studio in VS2010, though it’s a bit slower than using the tools built into browsers.

    • Clinton
      Mar 04 - 3:22 pm

      you are 100% correct

  5. [...] Why ASP.NET AJAX UpdatePanels are dangerous | Encosia [...]

  6. Gordon
    Jul 12 - 2:34 pm

    From your example, I fail to see how the UpdatePanel is in any way dangerous. Maybe verbose, but not dangerous…

    • Dave Ward
      Jul 12 - 2:43 pm

      When it comes to AJAX, I suppose danger is a relative term. However, needlessly increasing my employer’s bandwidth bill by a factor of 40 would certainly be dangerous to my continued employment.

      • Dave Reed
        Jul 13 - 2:08 am

        Compare it to the size of a regular postback to update that label, and you can say you’re saving that X% in bandwidth by employing AJAX. :)

      • gpa
        Sep 10 - 12:30 pm

        ah such hilarity wakes the dormant humor sectors of the grey matter I like to call my “conscious thought machine”

  7. adam
    Jul 16 - 9:33 pm

    Hello, may I ask what tools you used to show the headers post response) information (who on the screenshot)?


    • Dave Ward
      Jul 16 - 9:41 pm

      I use a FireFox addon called FireBug. I highly recommend it for any web development, and especially AJAX development.

      I think Fiddler is the name of a similar addon for IE, if you prefer IE.

      • Anonymous
        Jul 16 - 9:47 pm

        Big thanks for the quick response and information. I like your blog very much (by the way)

  8. Zack Owens
    Jul 17 - 1:00 pm

    UpdatePanels are so easy… why doesn’t Microsoft just fix them so that they return simple data and not a mishmash of stuff like in part 1 and not just simple text?

    • Dave Ward
      Jul 17 - 4:44 pm

      Don’t get me wrong. I think the UpdatePanel certainly has its time and place. If you need to modify ViewState asynchronously, it’s almost definitely the best way.

      They’re just overused, due to their ease of use and lack of proper warning about how they do their magic. I’m hoping this post will help a few people avoid that pitfall.

  9. Anonymous
    Jul 17 - 7:53 pm

    Hello Dave, I now know how to call the web service and return a string, but is there any way we can return more complex type like image, and how can I replace exist with new image on a web page?

    • Dave Ward
      Jul 17 - 8:21 pm

      If the image exists on the file system, you could return that URI in your Web Method and then update the image element’s src property in the OnSuceeded handler. For example:

      function OnSucceeded(result, userContext, methodName) {
        $get('img').src = result; // Where the Web Method's return is the new image URI.

      If you need to send a binary file stream with a generated image, you could use an ASHX handler as the src of the image element.

      • Ming
        Jul 18 - 7:28 pm

        Hi Dave, I tried last night for my dynamic binary image, and out of luck so far (CaptchaImage for register purpose, I allow user to click “try another” link, then ajax refresh and display a newly generated CaptchaImage). I try to use ASHX handler, which it return a image:
        // Create a random code and store it in the Session object.
        string code = GenerateRandomCode();
        context.Session["CaptchaImageText"] = code;

        CaptchaImage ci = new CaptchaImage(code, 200, 50);
        context.Response.ContentType = “image/jpeg”;
        // Write the image to the response stream in JPEG format.
        ci.Image.Save(context.Response.OutputStream, ImageFormat.Jpeg);

        but I have no luck getting it down to Ajax and display on the page.

        also I try direct:
        $get(‘captchaimage’).src = “Handler/CaptchaImageHandler.ashx”; it works some times (when I clear the cache), it appears to pick up the cache image rather than download the image from handler.

        • Zack Owens
          Jul 18 - 8:52 pm

          Why don’t you take a look at Subkismet ( They have a very nice CAPTCHA handler written for you.

        • Dave Ward
          Jul 18 - 8:54 pm

          Try changing your .src assignment like this:

          $get('captchaimage').src = 'Handler/CaptchaImageHandler.ashx?t=' + new Date().getTime();

          That should avoid any caching issues. It will append a dummy querystring argument with the number of milliseconds since 1/1/1970. This will convince the browser that it should load a fresh copy of the image on every load.

          Alternatively, I believe you can use “Response.Expires = -1″ in your image handler, to let the browser know it should never cache the image.

          • Ming
            Jul 19 - 7:01 am

            Thanks Dave, using appended milliseconds worked.

            also I am using the ASP.NET AJAX Web Service for user registration, I came across a article regarding the security of the web service (
            which suggest not to use AJAX web service for security reasons. I wonder what is your opinion on the web service security for ASPNET Ajax.

            • Dave Ward
              Jul 19 - 11:10 am

              I think he’s right to raise the issue, but perhaps a little bit too paranoid. You can secure web services in the same ways that you can secure other HTTP transactions. SSL, cookie/session based authorization, etc.

              For example, you could easily check User.IsInRole() for proper access rights before returning any business sensitive data, and encrypt it both ways through SSL.

  10. Joe
    Jul 23 - 4:19 pm

    21ms vs 16ms? I mean that’s alot granted and there is alot more bytes being passed, but come on… dangerous? A little much if you ask me. The whole point of partial postbacks is that you have a bunch of stuff on a page that doesn’t need to be updated. Therefore you aren’t passing more data, your passing less in reality. Additionally, more than likely if you’re going to do anything with the framework on .NET you need the functionality that the UpdatePanel brings vs. the pure javascript. Just my two cents.

    • Dave Ward
      Jul 23 - 4:45 pm

      Unless you plan on not allowing remote connections to any of your applications or only serving users with OC48s, those response times aren’t very meaningful to compare. All of that communication happens at the 4gb/s bandwidth of my local RAM. In practice, you end up with this sort of situation.

      It was actually a real world scenario that prompted me to post this. I’ve inherited an application at work that takes a 153kb partial postback to begin editing a GriwView row. Via LAN, it’s sluggish, but usable. Via WAN/VPN, it’s unacceptably slow.

      “The whole point of partial postbacks is that you have a bunch of stuff on a page that doesn’t need to be updated. Therefore you aren’t passing more data, your passing less in reality.”

      Keep in mind that you still pass the entire page’s POST information both ways, including full ViewState. Even if you’re only updating a single element, this overhead is incurred. Uploading a large ViewState over the average user’s WAN link is non-trivial.

  11. Dave Reed
    Jul 23 - 7:52 pm

    Not to disagree with this article in general, but it’s a bit misleading to call out how expensive posts via update panel are. The size of an Update Panel postback is just about the same as a regular postback. The response on the other hand is actually (usually) much smaller than the response from a typical postback response. In addition to the smaller size, since the rest of the page doesn’t reload, you get less requests to the server for images, scripts, stylesheets, etc etc etc. I would say in general, update panel postbacks are better for server performance than regular postbacks. I don’t have any numbers or studies to back that up, but it makes sense.

    The issue isn’t that Update Panels are expensive, because in many ways they are actually less expensive than the full postback alternative.

    The issue I think you mean to call attention to is that if all you want to do is update the value of a little label on the form, a postback in GENERAL is very expensive vs. alternative methods (such as webservices) — whether that be a regular postback or an update panel postback.

    People tend to blame UpdatePanel though I think in part because it’s so easy to wrap an UpdatePanel around this would-be scenario and call it done, not really realizing that you’re really still doing a full postback. That’s true I suppose.

    • Dave Ward
      Jul 23 - 8:09 pm

      I agree that partial postbacks are more efficient than full postbacks. Though, the upline payload is the same for both, which is the greatest majority of your average DSL/cable user’s transfer time.

      My purpose here isn’t at all to discourage UpdatePanel use across the board. What I want is to make people more aware of 1) the specifics of the partial postback implementation and 2) the fact that there are vastly more efficient alternatives in many situations.

      Maybe the UpdatePanel is just too good. It’s so easy to use that it encourages novice developers to greatly increase the number of postbacks their pages generate, without even realizing that’s what they did.

  12. Denny Ferrassoli
    Aug 07 - 2:44 pm

    UpdatePanels are great when you understand how to use them. I started working at a company a few weeks ago and revamped their AJAX apps. They had previously thrown everything into one UpdatePanel and the updatemode was not set to conditional. Yikes!! It was nearly as bad as a page refresh. If you’ll need multiple things updating within your page I would suggest placing only the necessary components within the panel and attaching only the necessary triggers.

  13. Kamlesh
    Aug 28 - 3:57 pm

    Dave, Thanks for the post and the link.
    You clearly show that by not using an UpdatePanel theres a lot of improvement in the amount of data that is passed for the entire HTTP round trip.

    I have another clarification..
    As ASP.NET developers, we are now used to developing pages using the plethora of ASP.NET server side controls like GridView, DetailsView etc
    So will we have to change the way we need to develop pages if we need to use AJAX?

    For example we need to display Grid like data, which also enables editing and deleting of records. In that case we use a GridView control in ASP.NET 2.0, Inorder to AJAX enable it i use the following option
    1) Using the UpdatePanel control and placing the GridView control inside it.

    Thatz the only option i know for such a scenario. And the amount of data that goes back and fro can be a lot as we have a Grid here.

    What are the other – ‘Non Update Panel’ techniques of achieving the same?
    All the examples i know just show client side Javascript calling a WebService method or a Method in a server side page which returns a string to Javascript

    Does anyone have any ideas?

    • Dave Ward
      Aug 28 - 4:27 pm

      I think there are still many scenarios where it makes sense to use an UpdatePanel (like the one you describe). It’s just important to understand the drawbacks and use them judiciously.

      In the GridView editing situation, the best course of action is probably to stick with the UpdatePanel, but optimize your ViewState and page life-cycle as much as possible.

  14. Manish
    Sep 12 - 2:50 am

    Hi All,

    If anyone has experience can they shed light on
    what is the difference between using PageMethods and

    And is it possible to return custom class, to the client?


    • Dave Ward
      Sep 12 - 3:08 am

      From what I understand, the PageMethods portion of ASP.NET AJAX and AjaxPro are very similar in implementation and functionality.

      Check out the JavaScriptSerializer class for information about passing custom classes via JSON in ASP.NET AJAX.

      • Manish
        Sep 12 - 5:07 am

        Thanks Dave for your swift response.

        Am I right in the following thinking:
        Ajax.Net Pro can call methods not only in the Page Class but also Functions in App_Code and Bin (Business and Data Access Layers) Where as MS Ajax PageMethods can only call codebehind or inline functions.

        Also the demo at Ajax.Net Professional (Press RunTest Button) show quiet an impressive data type handling including binary files.

        Your feed back would be appreciated.

    • Zack Owens
      Sep 12 - 5:21 am

      Ajax Pro also provides tools to expose your methods to the web. (It needs some work :)… but that’s a piece of functionality that Ajax Pro handles for you).

      Ajax Pro, on the down side, hasn’t been moving as a project. Last changeset was quite a while ago.

      I would give Ajax Pro a try. It’s good stuff.

  15. paul
    Sep 14 - 9:34 am

    I’ve kinda disliked UpdatePanels for a while now, based a good deal on the kind of analysis Dave shows here.

    Something that I’d like to point out to folks in the “it’s not worse than a regular postback” camp is the thought that, yes, for the scenario described above it’s the same as a regular postback (or better) in terms of wire usage… it’s impacting designs in ways beyond the regular form post pattern of submission.

    Many design patterns that folks use in non-updatepanel apps are frequently attempted in updatepanel-driven apps (e.g. use of the Timer to simulate continuous feed, using many hidden forms that independently reveal themselves, and so on) that result in partial postbacks happening more frequently than a full postback would have ahd the app been designed in a more ‘classic’ fashion.

    Further, I’d submit to you that with with an updatepanel-based POST, the page has to go through all or most of its regular page lifecycle (control creation, viewstate, stream writing, etc) *plus* it has to reformat the response to match the pipe-delimited format expected by the updatepanel callback. That’s going to result in more overhead *on* the server on a per-request basis.


  16. Anonymous
    Sep 28 - 5:10 pm

    You didn’t get a 4,000% improvement — more like a 50% improvement.

    I say this because the highlighted text was not the only text in that server round-trip. And, just because you did not see the text does not mean it’s not there.

    The exact amount of text on your round trip depends on a lot of details not mentioned here (like: what cookies does the site use?).

    Anyways… just be careful with your optimizations (try to be sure they are not premature).

    • Dave Ward
      Oct 01 - 2:36 pm

      A few minutes spent skimming the forums makes it very clear that this isn’t a case of premature optimization. A lot of people in real world scenarios are having trouble (or are working their way toward trouble) directly caused by this issue.

  17. Braulio
    Oct 02 - 5:06 am

    Mmmm… use webServices and PageMethods it’s quite nice on the server side, the pain on the neck it’s to update the client side using DHTML, updating a lable it’s fine, but updating a whole set of controls gets complicated.

  18. [...] Update panel case study October 1, 2007 Filed under: .NET 2.0, AJAX — dev1 @ 10:44 am [...]

  19. [...] Compare it to jQuery, that enables developer to specify what data gets exchanged, it is possible to exchange only the neccesary data (preferably in JSON format, since it can be used directly by client-script to update the view). For more detailed explanation, refer to Dave’s post. [...]

  20. Vyas Bharghava
    Oct 03 - 12:50 pm

    What you have shown is just a tip of an iceberg. In “real” applications, imagine having to send /receive the complete ViewState back and forth with EVERY request/response. To compute ViewState, ASP.Net renders ALL HTML [and throws away the unwanted HTML using a NullStream] everytime. One alternative is what you’ve shown and even that has the limitation of having to generate “JavaScript proxy” dynamically. I rather prefer a statically rolled Proxy to which I can control cache-policy.

    Another approach could be to use Classic Cross Page Posting [Nope, not the ASP.Net Cross page posting; this is just like good old ASP days where you could post to a different page].

  21. Anonymous
    Oct 24 - 3:10 pm

    I’m interested in returning a large dataset from my code behind file(C#), and binding it to a DataGrid on the client. My preffered method would be to convert the dataset values into JSON, and bind it to a YUI library DataGrid. Anyone know of any examples to get me started? ALL i have found online are simple hello world text examples, but nothing regarding large datasets. Also, if there is a better way of handling this please let me know.

    • Dave Ward
      Oct 24 - 3:38 pm

      Support for directly serializing a DataSet/Table/Row to JSON for web service and page method calls is coming soon. You can read more about that on Dave Reed’s Blog.

      Until then, converting your DataSet to a 2D array and returning that is your best bet.

  22. Anonymous
    Oct 24 - 3:50 pm

    I didn’t think javascript supported 2D arrays? What are your thoughts on using XML instead? Do you know of any examples or books using your suggestions?

    Thank you for the quick response!

    • Dave Ward
      Oct 24 - 4:01 pm

      JavaScript does support multi-dimensional arrays. They can be defined like this:

      var myArray = new Array(
        new Array('a', 'b', 'c'),
        new Array(1, 2, 3)

      or (this is the JSON notation):

      var myArray = [
        ['a', 'b', 'c'],
        [1, 2, 3]

      Personally, I would use JSON over XML. It’s much easier to work with in JavaScript, and more compact over the wire.

  23. Shail
    Oct 31 - 7:41 am

    I think its all about what is requirement. In Some cases using UpdatePanels is better than Web Methods.

    Each has its own pros and cons.

    Is there any way I can post back my viewstate with web methods ??

    • Dave Ward
      Oct 31 - 10:10 am

      Is there any way I can post back my viewstate with web methods ??

      Unfortunately, not very easily.

      ViewState is one of the most accurate indicators of whether you should use an UpdatePanel or not.

      If you absolutely must access the ViewState in your async operation, then you probably should use an UpdatePanel for that function.

      If you can find a way to perform the function without ViewState, then you don’t need an UpdatePanel for that.

  24. [...] Full article HERE. [...]

  25. Nuno
    Nov 08 - 11:04 am

    I was searching the web and found this very interesting article.

    I would like to make a question that I don’t know if is even possible: I’ve a dropdown and a treeview ( 2.0 controls) inside a tab panel ( ajax control).
    I want to update the treeview when the selected item of the dropdown changes.
    If I do this the “traditional” way (autopostback, even inside update panels) I get errors because these controls are inside a tab panel and I supposedly need to re-generate each tab on every postback (some strange issues, I know).

    So, I’ve though of using a web method to generate the treeview control code (html) and then put it in the corresponding div. This way, I wouldn’t need to postback so my tab panels wouldn’t disappear and need to be regenerated (or so I think…).

    Can anyone tell me if this is even possible (sending the html code of a treeview and updating the correct div on the client)?

  26. Geoffrey Swenson
    Nov 14 - 4:20 pm

    I got my feet wet with Michael Schwartz’ AjaxPro, so when Ajax.Net came out the early adopters at my company were showing me all of this stuff using the Update Panels. I was not very impressed with the incomprehensible objects required on the server to create the client-side functionality, the fact that these post back. Microsoft touts this as an advantage. NOT!!!

    I was pretty sure they were very verbose based on how slowly they appear, but a nearly two-orders of magnitude difference really is pretty convincing to me that they shouldn’t be used at all. I finally found the real Ajax inside Ajax.Net and I couldn’t be more pleased with the way it performs and at the ease of use.

    BTW, the form for this comment posting is a bit messed up in IE7.

  27. Tony
    Nov 21 - 1:08 pm

    I want to be able to select a value in a dropdown and based on the item selected enable or disable a textbox without using the update panel. can you help please?

  28. Geoffrey Swenson
    Nov 21 - 2:35 pm

    if you have a drop down list with id=”ddlItemList” and a Textbox “tbTextItem” this would be all it take. No ajax required, just clientside scripting.

    Note: If you are using a masterpage or control, you will have to use the client name of the control.

    function ListChange()
    var value = document.getElementById(“ddlItemList”).value

    var myTextBox = document.getElementById(“tbTextItem”);

    switch (value)
    case “Yadda”: case “Badda”: case “Bing”:
    myTextBox.disabled = false;

    myTextBox.disabled = true;



    I usually change the css class of the item to something that shows that the textbox is disabled more clearly:

    myTextBox.className = “dis”;

    //(with “dis” a css style that makes the textbox background grey)

    You will have to run this script on an appropriate event, such as “onChange”.

    In the code behind file (C# in my case) you can specify this by writing:

    ddlItemList.attributes.add(“onchange”, “ListChange()”);

  29. Tony
    Nov 26 - 3:07 pm

    Geoffrey, i am attemping to impliment but having some issues. im have tried using standard textboxes and html input (text) and neither one works. with the standard text boxes it doe snot like the work return in “RETURN ListChange()”. with the html textboxes it just get an error that says object expected. i am attemping to use html input text field within a tab contol.

  30. Jim
    Dec 09 - 8:32 pm

    It seems to me that generally an updatepanel should be used and web methods should be used in specific cases. There is a definitely a large percentage in bandwidth savings, but people seem to ignore the absolute numbers. If something is 10 times faster but only saves me 100ms, I’m not that concerned. Considering the vast majority of our visitors have DSL or faster, you have to save a lot of bandwith before it’s noticeable. I would consider the WAN/VPN cases to be very specific.

    It seems to me that full postback is easy to code but slow.
    Updatepanel is faster but a little harder to code.
    Web method is fastest and hardest to code.

    For me it comes down to development time/code efficiency.

    • Dave Ward
      Dec 09 - 11:34 pm

      In my experience, the difference is actually more pronounced in real world applications. I’ve got a page at work with a GridView that takes 2-4 seconds to perform any partial postback, over 768/6.0 DSL.

  31. Aron
    Jan 02 - 7:31 am

    I have a radio button list. Based on what the user selects I want to either show or hide controls.
    The update panel seems to take 2-3 seconds to reload. Which is way too long. Should I add a onClick JS event to the RadioButton List that would hide or show the controls instead or using the UpdatePanel?

    • Dave Ward
      Jan 02 - 6:35 pm

      You can definitely do that. You can use something like:

      // Hides the element with ID of ControlClientID
      $get('ControlClientID').style.display = 'none';
      // Shows the element with ID of ControlClientID
      $get('ControlClientID').style.display = '';

      If you want to show and hide groups of controls, contain them in a div, and use the same code on that div instead of the individual control elements.

      Just keep in mind that changes you make on the client side won’t be persisted through a postback (or partial postback), and plan accordingly.

  32. johnaspnet
    Jan 08 - 9:49 am

    How much work is involved when I need to re-populate a GridView server control using Web Method compared with Ajax UpdatePanel?

  33. Martijn Clarenbeek
    Jan 24 - 5:41 pm

    If you are concerned about posting large viewstates between client and server i advise you to consider implementing a persisted viewstate mechanism (load/reload viewstate from FileIO or other storage). That way no viewstate is send to the client and viseversa.

  34. [...] After one small change…which brings me to my next topic: UpdatePanels. Initially, these little dealios seem like a post-back avoiding savior. They’re extremely simple to implement allowing developers to essentially just execute server side, event-handler code for a control without a post-back just by including the control within an UpdatePanel. However, one soon realizes that attempting such a feat with even a slightly performance intensive control (such as a DropDownList with 1000+ elements), and the control becomes unusable; the reasons for which you will find: Here, in this person’s enlightening article. [...]

  35. Johan
    Feb 18 - 12:36 pm

    Hi David,

    Nice article. I’ve been working on an AJAX enabled project for a while, and I have been reading many articles. Yours is one of the few that do not endorse everything Microsoft produces.

    Anyway, here’s my question: what application are you using to view the request and response data? I’ve been testing http sniffers, but they do not suffice my requirements. I think that you’re using a browser plug-in, but can’t find which one. Please let me know.

    • Dave Ward
      Feb 18 - 12:45 pm

      Hi, Johan. I’m glad you found the article helpful.

      The addon I’m using in those screenshots is FireBug for FireFox. I very highly recommend it to anyone working with AJAX.

  36. Dan H
    Mar 11 - 2:04 pm

    Nice article!

    It solved an issue I was having attempting to use Client-side callbacks on a page with an UpdatePanel (it would randomly generate the “The state information is invalid for this page” error).

    Using PageMethods accomplishes what I need to do without requiring any type of postback which makes my page much more efficient and avoids the error mentioned above. Sweet!

  37. kannan
    Mar 18 - 4:55 am

    I am new in .net.
    Can you tell, how to see my page post and response like the above picture? Which tools will help me to show this result?

    Reply pls.


    • Dave Ward
      Mar 18 - 11:27 am

      The FireBug addon to FireFox is what I used for that.

  38. Anonymous
    Mar 27 - 5:07 pm

    Well, i think it totally depends on situation. If i want to have gridview with a nice look when update its value, how to use webservice or any rpc to complete this work ? yeah i know it is possible to create a full client-side gridview, but how many hours or days and how many budget to finish the job ???

  39. TheAgent
    Apr 09 - 3:03 am

    Although the method provided here can dramatically reduce the amount of data being sent back and forth between the server and the client, UpdatePanels, by their very nature, still help improve the performance of an ASP.NET page.

    Remember those days when you actually had to request the whole page every time a simple event took place on the page? And the Web used to work fine back then, too. Now, I think we are taking it too hard. Using UpdatePanels is still better than not using them at all and preferring traditional ASP.NET pages.

    I still prefer the simplicity of using UpdatePanels. Since I’ve been creating old-fashioned ASP.NET pages with no Ajax capabilities, I find UpdatePanels quite economical. Correct me if I’m wrong.

    • Geoff Swenson
      Apr 09 - 9:07 am

      Update panels are OK if you just have a couple of them. On a complex project, such as the one I just contributed to, all of the other developers used update panels, up to dozens of them per page.

      They are very slow. Even on a fast computer && connection, there is several-second wait for updates that would take less than a half-second with real Ajax. In comparison my own pages where I have a dozen or so interconnected REAL ajax objects running on the page are quite fast, and they are orders of magnitude easier to debug, since very little of the code runs inside the over-abstracted client-side javascript.

      The overly abstracted methods to attach client side events with update panels are also really difficult to read and use, and generate a lot of complexity just for simple tasks.

      One of the developers on this project had a weird adversion to writing even a single line of javascript and as such leveraged his considerable knowledge of DOT net to amazing levels of complexity to avoid writing any client side code.

      The result was a mess, despite all of his amazing brilliance. He had the same somewhat accusatory tone as the post I am responding to here, “You must not be doing it correctly” when I was trying explain that all was not good about this approach.

    • paul
      Apr 09 - 12:36 pm


      Have you done any benchmarking to support that updatepanels still help the performance of pages? I think you’ll find that it’s an incorret statement.

      It’s not just about bandwidth. In order for updatepanels to do their magic, the page postback still occurs the exact same way; the only difference is that it’s sent using XHR. On the server, the whole page lifecycle occurs, soup to nuts, before the ajax engine steps in to parse the response into the pipe-delimited format that updatepanels expect on the client. On the client, the browser’s javascript engine has to then take that response and parse it out to all the updatepanels on the page, which decide whether to update or not based on the parameters you’ve set, among other things. There’s also potentially some memory management issues, depending on how much ‘stuff’ is being sent back and forth.

      So, there’s some overhead there, on both ends of the pipe. Then, add in the fact that the *perception* is that these things are ‘lighter’, so folks try and squeeze more on there, or are more frequently sending posts back to the server, or possibly are using the AjaxTimer feature to do polling, etc, all of which impacts not only server resources and client memory, but also the pipes, since most browsers have a limited set of TCP connections that they’re willing to have open at any given time. (2 by default for IE, for example).

      the insidious threat here is that because they’re so easy to add to the page, developers don’t have to go through as rigorous a design process, which makes it easier to build a crappy appy. It reminds me of the reason why the qwerty keyboard was invented… the story I heard is that it was designed *specifically* to slow down typists back int he days of the manual type to make it harder for them to jam together the type arms.

      Just my opinion.

    • Dave Ward
      Apr 09 - 4:25 pm

      Then, add in the fact that the *perception* is that these things are ‘lighter’, so folks try and squeeze more on there, or are more frequently sending posts back to the server, or possibly are using the AjaxTimer feature to do polling, etc, all of which impacts not only server resources and client memory, but also the pipes, since most browsers have a limited set of TCP connections that they’re willing to have open at any given time. (2 by default for IE, for example).

      the insidious threat here is that because they’re so easy to add to the page, developers don’t have to go through as rigorous a design process, which makes it easier to build a crappy appy.

      I agree strongly with this. I participate in a lot of threads on the ASP.NET forums, and that’s a very common theme there.

      Especially when the Timer comes into play. It just begs a novice developer (especially one with a background in WinForms) to design things wrong.

  40. Dan Worley
    Apr 10 - 3:20 pm

    Thanks for the awesome article Dave. It’s great to see some examples of high performance AJAX with ASP.NET.

    One nice thing about the UpdatePanel and the ASP.NET AJAX framework is that it lets you get off the ground quickly, and show results to project stakeholders. This is especially important when the stakeholder has limited software development exprience and/or is unaware of the processes’ involved. We’ve all been there, if they can see it visually, it doesn’t exist ;).

    As the project grows, if performance becomes critical, you can always remove the update panels and convert to the JSON/webservice implementations described here. In fact I would say having the option is one of the nicest things about the framework. If performance was the number one priority driving projects, we’d all still be writing in machine language or assembly.

    Update panels give you “time to market”, which in today’s world is the most important driving force in software development. A good developer does not just write code a certain way because it is fast (fast to write, OR fast to run), they write the code because it is appropriate for the project requirements and scope.

    Understanding the trade-offs is the key, and this article helps developers understand the trade-offs of using UpdatePanels. Just my 2 cents.

    • Dave Ward
      Apr 10 - 4:30 pm

      I definitely agree with that. I don’t recommend abandoning partial postbacks completely. I use them myself, when appropriate (and for prototyping).

      I just think it’s very important for everyone to understand their drawbacks before running into said drawbacks. It’s easy to paint yourself into a corner with them, only to realize that fixing the problem will require major re-architecture.

  41. Mojtaba Vali
    Apr 23 - 11:43 pm

    but some times it is too difficult to render a component innerhtml via a web method (suppose that you want to rebind a combobox or grid ) what about that?
    but i think that it is ideal for readonly or simple event controls (event implementable by javascript) such as text and captions.but is there any way to use this method for complex controls?what if we use control.RenderControl such as this?

    public static string GetCurrentDate()
        StringBuilder SB = new StringBuilder();
        StringWriter SW = new StringWriter(SB);
        HtmlTextWriter htmlTW = new HtmlTextWriter(SW);
        return SB.ToString();
  42. Javier Diaz
    Apr 24 - 11:18 am

    Hi David

    Very nice article!

    I’ve been programming Windows Form for more almost 15 years now but I’m new to ASP.NET. We have been given the task to migrate a high complex windows app with a very heavy user interaction to Web app. The current windows app has a lot of grids to allow user modify different data sources, a lot of charts, reports etc. I totally understand your point about the importance to use carefully the UpdatePanels and that you should design your app properly. One of the big challenges we are facing though it’s how to achieve the same level of functionalities we have in the current windows app in the new web app we have to develop. Here is where my question comes. Do you know where I can find any good documentation about how to use these ASP.NET technologies “properly” when you have to build a Web app with a very heavy user interaction?

    • Dave Ward
      Apr 24 - 11:51 am

      Usually, those reporting scenarios are a great place to implement user control rendering through a web service call. That’s how a lot of prominent sites implement their dashboards.

      As long as the actual report data is read-only, using dropdown/textbox criteria to vary what’s displayed is easy.

      However, if you have grids of data that need to be edited, I think that can be one of the few situations where UpdatePanels can make sense. Later, if you find that you need to optimize certain ones that are heavily used, you can always upgrade them with faster, client-side techniques for those.

  43. Geoff Swenson
    Apr 24 - 6:13 pm

    If you need to rebind to drop down lists or a grid, then you really shouldn’t be using Ajax anyway, so you are stuck using fake ajax update panels.

    On the other hand, it is extremely easy to actually build your OWN html objects for drop down lists, radio buttons, and even html tables, that are scriptable on the client side. This is the way that you HAD to do it in classic ASP and it really isn’t that hard to write a short loop to create lists and tables in html. It seems like so many programmers have forgotten how.

    The sad thing is that so few of the builtin objects are really setup properly for CSS control or scripting. So I wrap some of these in my own user controls, and sometimes just roll my own, such as my own radio/check button control that actually builds good CSS using divs instead a badly formatted html table.

    You can also take advantage of dynamically generated objects and render them to html in a text stream, and send the resulting html back to the page using ajax.

    I never use the grid control since it is so overblown with features I will never need, but so difficult to use, and so slow, bog slow. I have my own much less feature laden grid control that does exactly what I need it to do, and creates clientside methods that make it easy to use with Ajax. Any time I need a new feature I can add it to my grid control in a couple of hours or less.

    The good thing about is that C# and page and control objects make it easy to build reusable, smart objects. My current project is full of these, and it makes for compact readable code and all of the various states and rendering modes of the controls are handled automatically, but with good context when debugging.

  44. Javier Diaz
    Apr 25 - 5:18 am

    Thanks a lot to both of you for your advice and suggestions. I’m honestly a bit sceptical at this moment about if we will be able or not to achieve in a web app the same level of functionalities we have in our current window app. Data entry represent more than the 80% of this app and the current Grids we are using are really high in features which current customers are used to like: filtering, grouping, summaries, columns customization, exporting to many different formats, etc. Also as the current windows app runs in the customer’s desktop; the speed has never been an issue.

    Moving to a web app will bring a lot of benefits mainly from the administration and support point of view, as the current app is being used by many customers in different countries; but we are really worry as users must keep all current features they are used to in the window app. Do you honestly believe that with the current technologies what we are planning to do is achievable?

  45. Geoff Swenson
    Apr 25 - 9:52 am

    There are some pricey but very high quality grid controls out there that do a lot of very kewl things, using real Ajax. They cost somewhere upwards of $500 per seat. I can’t remember the name of the company but googling should find it. If you really need this kind of functionality, the cost of the control is well worth the money.

    You are not going to have much luck with the built-in grid control. It is so difficult to use, to modify in appearance. And slow.

    • Geoff Swenson
      Apr 25 - 9:54 am

      I should mention that the $500 per seat is per programmer, not per client.

  46. Denny Ferrassoli
    Apr 27 - 11:45 pm

    I found this today: thought it would be interesting to share.

    (Pure AJAX Talk from ASP.NET Connections Orlando)

  47. [...] Worked fine on small grids with good connections.  But large grids with bad connections…not so much.  The problem was that the entire grid was being reloaded with every check box click.  Not good.  If you want to see more reasons on why to beware UpdatePanel see Encosia’s “Why ASP.Net AJAX UpdatePanels are Dangerous“. [...]

  48. Lilya
    May 16 - 8:11 am

    Hi, I’m working on several pages that utilize MS AJAX UpdatePanels. On the first page load it happens quite quickly – looking at the tracing everything is done within about 75 milliseconds. But when one of the components calls back to the server, the profiling/tracing indicates that a single step “build page” is taking over a second. In looking at the tracing for this, it seems to be a lengthy time for:
    .6 seconds for “adding http headers to disable caching” and
    .9 seconds for “starting renderings: sublayout”

    Both of which steps happen in about 15 milliseconds on a normal page load. Any ideas?

    • Dave Ward
      May 16 - 1:31 pm

      Most of what you’re seeing there is the work necessary for ASP.NET AJAX to slice up the rendered page and put it back together into the pipe delimited response that the PageRequestManager requires (as seen in the screenshots above).

  49. Matt
    May 16 - 1:32 pm

    Jules: Describe what modern browsers can parse!
    Dave: What, I-?
    Jules: Say what again. SAY WHAT AGAIN. I dare you, I double dare you, motherf–r. Say what one more g-ddamn time.
    Dave: Um, h-h-HTML…
    Jules: Go on.
    Dave: HTML 4.01 and XHTML 1.0 and CSS…
    Jules: Do professional developers use HTML 3.0?
    Dave: What?
    Dave: No!
    Jules: Then why you try to code it like it’s 1999, Dave?
    Dave: I didn’t.
    Jules: Yes you did. Yes you did, Dave.

    n00b: <script language="javascript">
    pro: <script type="text/javascript">
    • Dave Ward
      May 16 - 1:40 pm

      Hah, good point. Sort of missing the forest for a tree there though!

  50. Jon
    May 21 - 4:18 am

    By no means am I a guru on AJAX but surely using an AJAX update panel in most pages will be more efficient than posting the whole page back again. Most applications of using the update panel will be containing more controls & data than displaying the current date & time??

  51. Paul
    May 21 - 6:34 am

    Jon, no offense intended, but your comment leads me to believe you didn’t read the whole article nor the comments afterward.

    The fact is that when you use an UpdatePanel, you’re sending up the wire *exactly* the same request as you would if you were doing a ‘full page’ postback, regardless of what’s inside the update panel in question. Plus, there’s a small flag telling the server that it’s a partial page request.

    Once the request gets to the server, the ASP.Net runtime and your application will run the request through the *exact same* lifecycle (including building the control tree, deserilzing viewstate, etc) that it would go through on a full page postback, after which it converts the page output into a pipe-delimited string of data which it returns to the client.

    On the client, the clientside application has to take that pipe delimited string and parse it out to the appropriate spots on the page, updating the appropriate controls.

    So, in terms of bandwidth, you’re saving bandwidth on the response side, since you don’t have to return the whole page, just the pipe-delimited data string. But, you’re incurring additional overhead on processors (and possibly disks) on both ends of the request.

    Furthermore, the perception among developers is that updatepanels are ‘harmless’, so they end up using them more than they might otherwise do, or with more frequent requests via the timer control, and that ends up leading to more net requests against the server, which impacts resource availability and performance.

    I think what Dave’s about here, is trying to raise the awareness on these issues, and I think his article is a good one for doing that. Noone’s saying “never use updatepanels”, just advising developers to not consider them a free lunch, and to consider refactoring to other tools if the app needs to have performance at production time.


  52. [...] not the best way. There is many posts about performance problems related with UpadatePanel and here is just one of them. If you care about the performance you will transfer your data on some other [...]

  53. Kristian
    Jun 13 - 5:32 am

    Great article!

    Paul, no not quite exactly the same if it is partial update, it sends the full viewstate and post back information to the server and returns only the updated content for the update panel and also the full viewstate. No argue on the rest though…

    The problem of posting the viewstate using AJAX.Net is really dangerous in an environment like MOSS 2007 where pages exist having several web parts added.

    Imagine adding multiple controls heavily depending on viewstate. When adding your AJAX enabled control (using very limited viewstate) the combined viewstate of all the other controls will be sent, which means that others control on the page will cripple your control.

    Also I can’t agree that “most users have DSL” is a valid excuse for not developing high performing applications. A web server seldom hosts only one application in a corporate environment. The server will at some point run out of resources if not thinking. If having page visitors with low bandwidth on a site with low byte transfer… they can use it. If they’re on a high bandwidth connection… good for them!!!

    Currently I’m creating data islands redered by server side xslt. Of course you shouldn’t try to render ASP.Net controls when doing that but if you want to use AJAX enabled controls there is always the YUI framework. Otherwise it’s much like using update panels… just ask for the updates from the server, have it render the data (raw html+any javascript calls). There will be some overhead to using pure AJAX but it gives me a lot of advantages like valid xhtml, encapsulation, code reuse, use of multiple form tags and additional validation server-side.

    Another good thing is that you can make the data islands cross-platform server-side from the start.

    I would either use AJAX.Net or not. I don’t think that ASP.Net and AJAX.Net is a very good combination when considering the dependency that ASP.Net controls have on viewstate.


  54. Kristian
    Jun 13 - 5:38 am

    Paul… sorry. I re-read and I misunderstood… You wrote what I wrote!!!

  55. Paul
    Jun 13 - 9:23 am

    ;) No worries, Kristian.

    I think those that think along the lines as we’ve been talking will probably naturally gravitate toward the MVC framework and a client library like jQuery…

  56. Mark
    Jul 29 - 6:02 pm

    One of several great articles I’ve read on the topic recently.

    I do plan to convert quite a bit of the current app I’m working on to what could be described as ‘purer’ more efficient AJAX calls. However, as mentioned in the comments a few times the speed of adding UpdatePanels and requirements to have a working app quickly mean I’m going with updatepanels for now for most of the app (though I do have some scriptservice calls already).

    A question I have though is whether there is a performance hit with an increased number of panels. I ask as I have a table of textboxes with 5 columns and up to 10 rows. Only 1 column requires updating so my choice appears to be:

    a) 1 update panel that updates the whole table
    b) 10 update panels that update the individual cells

    Which is more efficient and where i.e. server, request, response, client.

    As an aside I have another area of the app where a single row required updating. I therefore set it up as:


    But rather than update the row a new row was being created outside and just above the table – a bug? a limitation?

    I actually decided to implement a scriptservice for this part of the app but would be useful to know if any of you have any thoughts on why this wouldn’t work.


    • Dave Ward
      Jul 29 - 7:25 pm

      Hi, Mark.

      While using more UpdatePanels technically does reduce the amount of data returned to the client, I’ve found that’s almost always negligible compared to the rest of its performance drawbacks.

      I would suggest subdividing UpdatePanels based on usability concerns more than hoping for performance gains.

      The reason that the UpdatePanel broke your table layout is that it renders as a div, which makes a mess when injected right there.

  57. Mark
    Jul 30 - 8:09 am

    Thanks Dave. I’ll perhaps give the multi-update panels a test and see if there is any performance improvements. That said the more I think about it the more likely I am to but it into a pageservice to ensure that only the relevant values are updated. Though this will increase server load (as the code will effectively have to be run twice).

    The reason I asked is because adding the extra pane to update this particular area seemed to visibly slow things down. I actually think the slowdown is client side since the progresspane gif stops spinning. My feeling is that destroying and recreating the full table takes significant javscript.

    Of course – the div! That’s what you get when you work on the train home after a 5am start! On the plus side it forced me to use a web service which is much better for this part of the App. Out of interest, do you know if it is possible to subclass the updatepanel and produce a usercontrol that renders as a tablerow or some other html element? I haven’t quite thought it through yet for this would seem a useful addition..


  58. Jin
    Sep 03 - 3:43 pm

    I’m still fairly new to programming web applications, and would very much like to know how one gets the information contained in the headers, post, and response fields shown in the pictures. Sorry if this has been posted before.

    • Dave Ward
      Sep 03 - 3:49 pm

      Those are from the console tab of Firebug.

  59. Sam
    Sep 07 - 6:08 am

    I disagree with your opinion.
    With relatively large pages, ASP.NET AJAX can effectively elminate the response size since without it, the whole HTML page must be re-rendered while in AJAX, only required parrts are sent in response.

    It is necessary for any postback data be shown in HTTP request data even without using AJAX — it is not a threat at all

    The real threat is that programmers jam the AJAX by outputting too much over the client, causing the browser to hang due to too much js processing

  60. Geoff Swenson
    Sep 07 - 9:16 am

    Too much JavaScript processing is an unrelated issue.

    The main problem with Update Panels is that the entire page is posted back. If it a large page as you suggest, that means every item on the page is sending back data. The worst problem, is the huge viewstate data that gets sent back so that the all of the complex stateful handling in asp.NET is maintained.

    If you are worried about javascript handling, there is nothing that prevents you from sending back a string of html that gets inserted into the innerHTML of an element on the page.

    As long as you do it properly, using the free CPU cycles on the clientside to handle some of the work in displaying the page is a great way to offload work from the server. If you do too much of it or do it poorly, of course it isn’t appropriate, but it is hardly a justification to continue using update panels.

    I will also suggest that the UpdatePanels run a lot of Javascript themselves to acheive the functionality, and if it is anything like the overly abstracted client-side validation code, it would be verbose and very slow.

  61. Dave Ward
    Sep 07 - 11:27 am

    With relatively large pages, ASP.NET AJAX can effectively elminate the response size since without it, the whole HTML page must be re-rendered while in AJAX, only required parrts are sent in response.

    The problem with that line of thinking is that it’s focusing on the best of two bad choices, while much better choices exist.

    • Geoff Swenson
      Sep 07 - 10:02 pm

      There is a little bit of confusion going on here, most of it Microsoft’s fault, because of the way that they equate updatePanels == AJAX, which in reality, it is NOT.

      But even though updatePanels are NOT really AJAX, Ajax.NET has real ajax functions that work very efficiently to handle client side data driven interfaces that are much more responsive to the user than relying on page postbacks. For me, implementing a real AJAX page both reduces the load on the server AND provides the user with a much better experience, since they can fill out the form dynamically, with contextual inputs.

      For example, they select a state, and then the server sends back a list of valid zip codes in the background, so that as soon as the user types an invalid zip code, it is flagged. You do this kind of active validation for every control on the page, and you don’t have to force the user to post back the page and wait repeatedly until they get every data element correctly selected or filled out.

  62. [...] the post from Encosia (Dave Ward) before, but I was reminded on the Twitter by MasterMaq about how dangerous UpdatePanels are a week or two [...]

  63. Sean Amos
    Oct 24 - 7:45 am

    UpdatePanels are incredibly inefficient and actually add additional overhead, though they can reduce the amount of bandwidth used as opposed to full round trip.

    I personally don’t use UpdatePanels in high traffic sites, and stick with my javascript library of choice and web services/ajax pro etc. etc. (Page Methods only allow you to call static methods on the current page, which leads to many widgets that aren’t re-usable and an incredibly cluttered code-behind).

    While its really easy for a novice to slap a few UpdatePanels on a page and show off some cool things to the boss, you pay a performance toll, and it will come back to bite you.

    The only realy world scenario you could be using an update panel is in a back office app under tight time constraints, otherwise, you really should be doing it properly.

  64. Mark
    Nov 18 - 6:22 pm

    Great article … what tool are you using to view your Post and Response?


  65. Chintan Shah
    Nov 28 - 7:45 am

    How can I return DataTable from PageMethods and assign that DataTable to DropDown?

    I have Country DropDown and I want to fill States DropDown using PageMethod.

    Thanks in Advance…

    • Dave Ward
      Nov 28 - 1:05 pm

      You’d be better off using the Cascading Dropdown Extender than reinventing that wheel.

  66. martin
    Jan 09 - 7:24 pm

    That was alot of reading :o)

    First of all i don’t use updatepanels at all. I also don’t use ajax as it is almost 100k of javascript code. jQuery, Prototype, Mootools ect. is a lot lighter and so far i have been able to make calls to webmethod’s with both jQuery and Mootools.

    Regarding the normal postback using, well then i normally don’t use a form with runat=”server” as i found that the repeater can be used without it. This way i’m creating lightning fast web apps using normal html form elements, asp:repeater and javascript calling webmethod’s on the serverside.

    I know this take away the abillity of using the most of’s web controls, but with the performance boost i get without postbacks i simply can’t see any reason to why i should use them.

    People often ask me why i even use then. Well i still get the abillity to write OOP code at the backend wich i prefer rather than old asp or php for that matter.

    And just to point it out, a generic list of say 500 records loaded into json and displayed on a page takes about 200ms to load.

    Have a nice day ;o)

  67. chris wigley
    Jan 16 - 12:24 am

    If you store the viewstate in the database, you won’t send it over the wire when you do full or partial postbacks. Storing viewstate in the db easily allows you to use the updatepanel w/o the potential performance problems described in the article.

    • Dave Ward
      Jan 17 - 11:24 am

      That shifts the problem to another bottleneck point, but doesn’t eliminate it. Both ways, you still have the same overhead of reinstantiating the entire Page and running it through its lifecycle.

  68. Chintan Shah
    Jan 19 - 4:23 am

    Hi, I am using PageMethods to fill DropDowns. Can any tell me how to call the WebMethod that is defined in other class?

    Say, I have Class called “CommonFunctions” and I have defined WebMethods to fill States, Counties in that Class. How can I call that methods in javascript?

    Something like:



    • Dave Ward
      Jan 19 - 7:51 am

      You can’t directly call a method outside the page’s codebehind as a page method.

      What you can do is create stub page methods at the page level that act as proxy for your “CommonFunctions” methods. E.g.:

      public static string[] FillStates() 
        return CommonFunctions.FillStates();

      It sounds like you’re working on a set of cascading dropdowns. You might consider using the CascadingDropDown extender instead of rewriting it yourself.

      • Chintan Shah
        Jan 19 - 11:44 pm

        Thanks for quick reply.

        Another question ! Is “PegeMethods” is same as “Client Callback”?

        If not, then which is better than other?

        • Dave Ward
          Jan 20 - 8:13 am

          “Client Callback” might refer to using ICallbackEventHandler which is a more primitive mechanism, introduced in ASP.NET 2.0. Since ICallbackEventHandler transfers the ViewState, it is more comparable to the UpdatePanel than PageMethod.

          For many of the same reasons given in the post above, I would consider PageMethods better.

  69. [...] we intended to update. Still, the UpdatePanel control has some drawbacks which one of them is that it carries extra data with [...]

  70. Chintan Shah
    Feb 11 - 7:22 am

    How can I use PageMethods on master page?

    I am getting “PageMethods is undefined” error, if I use PageMethod on master page.

    • Dave Ward
      Feb 11 - 8:53 am

      You can’t.

      An ASMX web service is a good replacement. With the [ScriptService] attribute, they are functionally interchangeable with page methods.

  71. [...] del ViewState, este estará viajando entre los postbacks asíncronos, revisar este artículo para ver un ejemplo. Además de que ASP.NET AJAX es un framework centrado en el Servidor [...]

  72. [...] del ViewState, este estará viajando entre los postbacks asíncronos, revisar este artículo para ver un ejemplo. Además de que ASP.NET AJAX es un framework centrado en el Servidor [...]

  73. [...] module in DotNetNuke.  I know using UpdatePanels is considered a bad thing (see related post at Encosia for an explanation), but in this case I had tight timelines, and the improved function I felt [...]

  74. [...] que tengo es el uso de los UpdatePanels. Si no se saben usar, pueden resultar muy peligrosos. Éste post muestra un ejemplo de ello. Creo que una de las características más peligrosas de los [...]

  75. Paul Hennessey
    Apr 30 - 3:45 pm

    Firstly, thanks for keeping this informative and courteous thread going so long.

    I’ve been wrapping a ListView in an UpdatePanel, and have run up against some of the performance problems described above. Is it possible to use the PageMethod techniques you’ve described to amend elements in a ListView?

    • Dave Ward
      May 02 - 5:33 pm

      You could definitely use the result of a page method to modify a ListView’s elements on the client-side. That’s especially easy if you’re using jQuery.

      However, you would need to keep in mind that the ListView’s ViewState wouldn’t be updated as you modified its HTML elements. If your scenario included client-side updates and postbacks affecting/inspecting the ListView, you’d need to be careful and keep that issue in mind.

      • Paul Hennessey
        May 03 - 1:31 pm

        Thanks Dave – I haven’t looked into jQuery yet, I’ll check it out.

        As far as the ViewState is concerned, I think that I might be able to get away without doing any postbacks.

        We’ll see!

  76. [...] Why ASP.NET AJAX UpdatePanels are dangerous [...]

  77. Pankaj Pravin
    Oct 19 - 3:56 am

    Hi Dave,

    I have a problem in applying above. It works fine without master pages, but when we put master page an error comes “Microsoft JScript runtime error: ‘null’ is null or not an object”


  78. [...] Namun demikian dari pengalaman penulis, kita harus bijak dalam memasang script  UpdatePanel ke dalam halaman ASPX. Walhasil bukan halaman bertambah cepat saat merequest, tapi malah bertambah lambat. Selidik punya selidik ternyata UpdatePanel ini bukanlah “Real AJAX”. Begitu penulis mengungkapkannya. Karena walaupun menggunakan obyek XMLHttpRequest, UpdatePanel masih menggunakan actual HTTP post dan response untuk melakukan partial postback. Penjelasan silakan lihat di sini. [...]

  79. Ice Chelsea
    Dec 16 - 12:57 pm

    Need help!
    I’ve been using in the last couple of months and what I (and i suppose all of you) hate the most is the reloading of the whole page when something has to be changed. So I want to do some things using ajax (which i have no expirience in). But so far I haven’t been able to make any kind of client-side – server-side communication. I’ve tried the example on this page but I can’t get it to work either. When I press the web method update button nothing happens. Will somebody PLEASE post an example of the client-side (Default.aspx) and server-side (Default.aspx.cs) files, but not just part of the code i need the whole code, including the using directives.
    I have Visual Studio 2005 installed, .NET Framework 3.5 SP1 and ASP.NET 2.0 Ajax Extensions 1.0.
    I need the most simple example (a single string to be transfered between the two files) and since I can’t make it work anyhow, it would be greatly appriciated if you give me all of the steps to do it. All I have is a blank Default.aspx page in the environment i mentioned :).
    Thanks in advance, and again, any help would be appriciated
    p.s. Can all this work withoud a WebService?

    • Dave Ward
      Dec 16 - 2:03 pm

      Here’s the website project I used when writing this post:

      • Ice Chelsea
        Dec 16 - 10:23 pm

        Thank you, it helped a lot. It came out that the problem was in the web.config file, in fact the problem was in me, I never created an Ajax enabled web site when starting the project, I was always choosing a normal website. Thanks again, especially for the fast response…

  80. Nathan
    Feb 01 - 4:13 am

    Hi Dave,
    Is there a way to optionally add/remove triggers? When selecting a new item in a DDL, I want to do a full postback to clear my grid. I don’t, however want to do a full postback if the grid is empty.

    I thought I could query the visible property, but it’s not set in Init, and by Load time it appears to be too late to add stuff.

  81. kenntrix
    Feb 17 - 12:51 am

    thanks. this helps me a lot.

  82. Mohammad
    Mar 13 - 9:25 am


    Bad choice of words.

  83. xxx
    Mar 19 - 6:08 am

    It depends. For example, in intranet applications it’s same 20 bytes or 20kB – both is very small ammount of data. So what is point to use more difficult “real” AJAX? In your example real difference was 5 ms (16 against 21), so win isn’t 4000%.

    • Dave Ward
      Mar 22 - 6:12 pm

      As you can imagine, the gap widens even more significantly as your Page becomes more complex. What’s even more significant in an intranet application is what those massive ViewStates are used for, more than their transfer overhead. The performance penalty quickly becomes prohibitive.

      It was actually a poorly performing intranet (as in, all users connected within one switch, via gigabit) application that originally inspired this post.

  84. Hoa Nguyen
    Mar 22 - 5:58 pm

    Hi Dave Ward,
    Thank you for your post, It’s useful for me. Besides, I have one question. How can we pass parameter when we call a web method in the code behind? say: I have a link button in a datagird, and I want to to pass that link button and item index to web method.
    Great thanks

    • Dave Ward
      Mar 22 - 6:09 pm

      To identify which LinkButton was clicked, you could do something like this in a click handler (wired up with either $addHandler or jQuery):

      LinkButton_Click(evt) {
        // "this" will be a DOMElement reference to 
        //  the clicked anchor element.
        PageMethods.YourMethod(, YourSuccessHandler);

      Then, parse out what you need to know from the ClientID in YourMethod. There are a wide variety of more sophisticated methods for overloading the elements with metadata, but that’s the basic approach.

      • Hoa Nguyen
        Mar 23 - 11:14 am

        Thank a lot for your help

  85. Jashua Newway
    Apr 26 - 5:26 am

    Hi, there is a safe, easy and free way to use ajax in Try PokeIn ajax library.

  86. [...] Unlike an ASP.NET UpdatePanel we only pass what we need; we only receive what we need. We don’t pass ViewStates, in fact we don’t even have a ViewState. We also don’t pass entire HTML chunks and receive HTML chunks we don’t use. For more on this; read: Why ASP.NET AJAX UpdatePanels are dangerous. [...]

  87. [...] Unlike an ASP.NET UpdatePanel we only pass what we need; we only receive what we need. We don’t pass ViewStates, in fact we don’t even have a ViewState. We also don’t pass entire HTML chunks and receive HTML chunks we don’t use. For more on this; read: Why ASP.NET AJAX UpdatePanels are dangerous. [...]

  88. [...] This website will explain exactly why UpdatePanel’s are dangerous: – [...]

  89. Ben
    Jul 13 - 10:17 am

    Excellent tutorial – I have a scenario that requires multiple labels to be updated using a single button click. Would you be able to share a code example that would handle this scenario using the page method approach? It would be much appreciated.

  90. Luiz França
    Aug 11 - 10:50 pm

    Your post is really great! I’ve been learning a lot reading these articles!
    I love web development and i like to improve my knowledge about performance in web sites. congratulations!

  91. krislogy
    Aug 24 - 4:31 am

    Sorry, but i’m having a little difficulty understanding how to pass parameters to the webmethod.

    the main article describes the way to call a web/pageMethod, by:
    function UpdateTime() {
    PageMethods.GetCurrentDate(OnSucceeded, OnFailed);
    so, here OnSucceeded and OnFailed are the different javascript functions acting based on the result.

    But in the reply to Hoa Nyugen,
    LinkButton_Click(evt) {
    PageMethods.YourMethod(, YourSuccessHandler);
    the params passed to the page method are different. Is it that this is overloaded, and that these are the two different ways we can use it? Or is the evt.preventDefault() is the key to this puzzle?

    Pls explain. Thx

  92. Adit Shah
    Sep 29 - 2:06 am

    Hey DAVE, What should I do If I want to make an image of “Please Wait” while asynchronous post back?

    • Dave Ward
      Sep 30 - 9:14 pm

      There’s an UpdateProgress control designed for that purpose.

  93. Pawan
    Oct 06 - 1:53 am

    Great post man!
    I got many things from it that I did not know.

  94. Mesfin
    Dec 05 - 2:47 pm

    Thanks Man!

    Very good post, It clears so many doubts about Ajax, Update Panel and JSON to me.

  95. [...] Regarding those articles:Update Panels and JSON AlternativesWhy ASP.NET AJAX UpdatePanels are dangerousPageMethods vs UpdatePanelsI think AJAX UpdatePanels can’t be the appropriate way of [...]

  96. cem
    Feb 15 - 6:40 pm

    I agree with the speed of content coming from database.
    Jquery with ajax is very faster than update Panel, however I have some doubts on security. I have researched a lot of articles containing this topic. Each time I have ecountered the security lack of ajax.

    I am now in dilemma, which is the best : security part with less speed or more speed with insecure ajax?

    • Dave Ward
      Feb 15 - 10:06 pm

      ASMX/WCF can be secured by ASP.NET authorization just the same as ASPX pages. Unauthorized, external requests to the services will throw HTTP 401 errors, just as you’d expect from unauthorized access to any other resource.

  97. Anshul
    Feb 21 - 2:44 am

    I have a one page and 5 anchor tag in left menu. apart from this I have one Update Panel and one Place Holder in my page.
    I have created 5 user control, which I am loading in place holder via update panel. (because I don’t want to submit my whole page, which is having lot of content in footer and header). I pass id of anchor as a event argument to load proper user control.
    Now i want to know , Is this approach is good in the term of view state and performance or do we have any other better approach ???

  98. Boberts
    Mar 04 - 6:11 pm

    Ya know if this were 1994 and we were all on 28.8 modems with machines using pentium processors using trumpet winsock on windows 3.1, I might give a crap about this piddly amount of extra data. This extra amount of overhead is like cutting the federal budget 100 million dollars… who cares.

    • jhonatan
      Mar 21 - 3:21 pm

      I care.
      For a webform where you edit/update/insert only one register, UpdatePanels are OK.
      But for showing a big amount of data (paged results) on a site with average 1000 concurrent users, PageMethods and JSON is the solution.
      Replacing GridViews/UpdatePanels with a PageMethods/JSON solution, improved my site perfomance (because NO VIEWSTATE = less network traffic).

  99. [...] on UpdatePanels that I constantly refer developers to is Dave Ward’s blog post titled “Why ASP.NET AJAX UpdatePanels Are Dangerous“.  The post does a great job of discussing the point of UpdatePanel overuse and gives an [...]

  100. KrishPuneet
    Mar 22 - 7:19 am

    Thank’s Buddy for your valueable information regarding JASON,Javascripts against Update panel.

  101. Brett
    Jun 26 - 9:15 pm

    Great post even 4 years later!

    This seems to be a great way to reduce the overhead that comes along with the UpdatePanel. But what about when you need to access data from the page? For example if I have a variable that I’m storing in ViewState or even one that is part of the Page object I would not have access to it because the page methods must be static.

    Is there a way to do some intarction with the object using Page Methods and JSON?

  102. Hardik
    Sep 05 - 7:12 am

    Great post even i am late :(

    is there any way to reduce the page while page haveing gridveiw edit,delete, add functionality and i have put gridview in updatepanel so page dont refresh…

    Hardik J. Desai
    Asp.Net,C# Developer.

  103. Shaw
    Sep 11 - 12:54 pm


    Thanks for posting this. I just started developing in ASP.NET and have been using UpdatePanels on most of my pages.

    Every tool has its uses and it seems like there are times where in the search for the best possible performance that UpdatePanel isn’t always the right tool.

  104. Sumant
    Dec 21 - 5:36 am

    I think update panel really provides good functionality,it is any way better than writing hundreds of lines of jquery code which is very hard to debug.Also you can use validators with update panel very easily.

    • Dave Ward
      Dec 21 - 5:24 pm

      You can replace most UpdatePanels with just a few lines of jQuery, not hundreds. That doesn’t address the underlying inefficiency of the partial rendering approach when coupled with ASP.NET’s page life cycle though, so it’s really a moot point either way.

      • sumant
        Dec 24 - 6:37 am


        I had a situation in my project where i had to add controls like textboxses and drop down lists dynamically to the page on the click of a button,i had the jquery clone method with which i could clone controls,but the issue was how could all the data on postback,also i had to apply validators to the dynamic content which was coming on the page,i not only used update panels but also validators for all controls and i was able to add validators as well as the controls to the page because of the update panel, i cannot see a solution in this case without a update panel,can you tell me how could i have used jquery in this case?

        • Dave Ward
          Dec 24 - 2:04 pm

          You can use the jQuery Validation plugin instead pretty easily:

          That’s the approach ASP.NET is moving toward anyway. MVC 3 already uses jQuery Validation and I believe WebForms is moving that direction too in 4.5 or later, using the same unobtrusive wireup approach to bridge the gap between ASP.NET and the jQuery plugin automatically.

  105. Sumant
    Dec 26 - 2:32 am


    Hi as i had posted this will probably solve my validation problem but do we have anything in jquery so that we can add controls to the page dynamically and i need controls to be added dynamically on click of a button,so that on postback i can all data from the controls.If you ahve any work around for this do post.

  106. Roberto Alessi
    Jan 21 - 1:13 pm

    So in a “real” high traffic site i shoud consider to work only by web services (.asmx files) ? throw away asp:Button with the “onclick” code behind ?

    • Dave Ward
      Jan 23 - 11:28 am

      I would say that avoiding the WebForms Page life cycle is definitely key for scalability and performance. Another option, if you want to stay more on the server-side, is using ASP.NET MVC instead of ASP.NET WebForms.

      • Roberto Alessi
        Jan 23 - 1:51 pm

        So asp:Button with server side _onclick only for fast development of service pages (user membership management for example) and only web services/page methods for production pages.
        I was only asking a confirmation for this radical change.
        I have briefly look at MVC but IMHO is better to work by web services / page methods.
        It is better to work only by web services ? or static page methods are acceptable for private routines that does not need to be public exposed ?
        Thanks for your answer.

        • Dave Ward
          Jan 23 - 1:56 pm

          Yes, the WebForms Page model is optimized for rapid/easy development, not so much for performance at runtime.

          If you use MVC, you can still do something very similar. You can have controller actions that don’t do anything but return some JSON, just like page methods and ScriptServices.

          Either way, the key is to use light weight AJAX calls for small bits of information, instead of re-rendering the entire page on the server-side for every interaction.

  107. [...] Why ASP.NET AJAX UpdatePanels are dangerous [...]

  108. Presentation | Pearltrees
    Apr 10 - 10:30 am

    [...] Simple enough. Button1 is clicked, an asynchronous request is made for the current date/time, and that is displayed as Label1′s content. As simple as it sounds, take a look at the actual HTTP post and response necessary to accomplish the partial postback: protected void Button1_Click ( object sender, EventArgs e ) { Label1. Why ASP.NET AJAX UpdatePanels are dangerous » Encosia [...]

  109. [...] I checked that the response is talking very long time after using Update panels…Here is the study material. I have a Delete Command event in Datalist and works find in the above mentioned case. I was trying [...]

  110. WorkToWindsurf
    Aug 02 - 7:58 am

    Is this an accurate summary of the way AJX Panel Partial Postback works?:
    1. It initiates a POST passing all the Post information
    2. The Post information includes the entire ViewState
    3. The Server runs all Page_Load code and builds all the HTML for the entire page
    4. The Server sends back the HTML required to render the AJAX Panel, together with the entire ViewState

    • Dave Ward
      Aug 02 - 9:45 am

      That’s the gist of the process. The partial response also includes extra data like scripts that should be executed after the update, which UpdatePanel(s) to update, etc. So, the client-side portion of the framework has more work to do to parse that out after your step 4, before the UpdatePanel is refreshed.

  111. WorkToWindsurf
    Aug 03 - 3:52 am

    Thanks for that.

    I’ve been digging a little deeper a found some odd behaviour.

    It looks like the post back behaviour is actually:

    1. It initiates a POST passing all the Post information
    2. The Post information includes the entire ViewState
    3. The Server runs all Page_Load code and builds all the HTML for the entire page
    4. The Server sends back the HTML required to render ALL THE AJAX Panels – Not just the AJAX panel you posted from, together with the entire ViewState

    Thats certainly NOT what I expected!
    It even re-renders all the AJAX panels when you post from a Sub AJAX panel…
    Please find code sample below – sorry – but I use VB ;(
    If you click on any of the buttons within the AJAX panels, all the PAGELOAD labels are updated EXCEPT the one that is NOT in an AJAX panel.

        <asp:ScriptManager ID="ScriptManager1" runat="server">
            <asp:Button ID="Button0" runat="server" Text="Button" />
        <asp:Label ID="Label0" runat="server" Text="Label"></asp:Label>
        <asp:Label ID="Label0B" runat="server" Text="Label"></asp:Label>
                    <br />
                    <br />
                    <br />
            <asp:UpdatePanel ID="UpdatePanel1" runat="server">
                    <div style="border: medium solid #0000FF">
                    Ajax panel 1
                    <br />
                    <asp:Button ID="Button1" runat="server" Text="Button" style="height: 26px" />
                    &nbsp;<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
                    <asp:Label ID="Label1B" runat="server" Text="Label"></asp:Label>
            <br />
            <asp:UpdatePanel ID="UpdatePanel2" runat="server">
                     <div style="border: medium solid #0000FF">
                     Ajax Panel 2
                    <br />
                    <asp:Button ID="Button2" runat="server" Height="26px" Text="Button" />
                    <asp:Label ID="Label2" runat="server" Text="Label"></asp:Label>
                    <asp:Label ID="Label2B" runat="server" Text="Label"></asp:Label>
            <br />
                    <br />
                    <br />
                    <br />
                <asp:UpdatePanel ID="UpdatePanel3" runat="server">
                    <div style="border: medium solid #0000FF">
                    Ajax panel 3
                    <br />
                    <asp:Button ID="Button3" runat="server" Text="Button" style="height: 26px" />
                    &nbsp;<asp:Label ID="Label3" runat="server" Text="Label"></asp:Label>
                    <asp:Label ID="Label3B" runat="server" Text="Label"></asp:Label>
                                <asp:UpdatePanel ID="UpdatePanel4" runat="server">
                    <div style="border: medium solid #FF00FF">
                    Ajax SUB panel 4
                    <br />
                    <asp:Button ID="Button4" runat="server" Text="Button" style="height: 26px" />
                    &nbsp;<asp:Label ID="Label4" runat="server" Text="Label"></asp:Label>
                    <asp:Label ID="Label4B" runat="server" Text="Label"></asp:Label>
        Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
            Me.Label0.Text = "PageLoad: " & Now()
            Me.Label1.Text = "PageLoad: " & Now()
            Me.Label2.Text = "PageLoad: " & Now()
            Me.Label3.Text = "PageLoad: " & Now()
            Me.Label4.Text = "PageLoad: " & Now()
        End Sub
        Protected Sub Button0_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button0.Click
            Me.Label0B.Text = "Button0 clicekd in ajax panel " & Now()
        End Sub
        Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button1.Click
            Me.Label1B.Text = "Button1 clicked in ajax panel " & Now()
        End Sub
        Protected Sub Button2_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button2.Click
            Me.Label2B.Text = "Button2 clicked in ajax panel " & Now()
        End Sub
        Protected Sub Button3_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button3.Click
            Me.Label3B.Text = "Button3 clicked in ajax panel " & Now()
        End Sub
        Protected Sub Button4_Click(ByVal sender As Object, ByVal e As EventArgs) Handles Button4.Click
            Me.Label4B.Text = "Button4 clicked in ajax sub panel " & Now()
        End Sub
  112. panos roditakis
    Jan 04 - 3:12 pm

    I think that the size of bytes are not dangerous, but the fact that developer can overuse updatepanels causing multiple page initializations on server, consuming it’s valuable resources especially when dealing with database connections etc. Using usercontrols in developing increases the risk of initializing too many times too many things. Bandwith is not my main concern using ajax in webforms.

  113. [...] Panel: not hard to implement but I suggest you to read Dave Ward’s blog – Why ASP.NET AJAX UpdatePanels are dangerous and have more understand on how it works before you consider to implement [...]

  114. Brad Leydorf
    Feb 20 - 3:57 pm

    You helped me out about 6 months ago with hooking up jquery to webservices for ajax calls.
    I’m starting a new project where I’m taking an existing application that used tons of (evil) UpdatePanels, and going to convert it into a C# (already done), that uses jQuery Ajax instead of the UpdatePanels.
    The updatePanels are used to keep the website from posting back on a plugin we’re using that connects to a third party app with an emulator, which if a postback occurs on the page, will zap the Emulator instance. As far as switching these UPs to jQuery, I’m having trouble with how exactly I’ll do that, the various controls that are currently contained in the UPs, and I guess conceptually as well.

    Thanks for any help you can offer,

    • Brad Leydorf
      Feb 22 - 2:40 pm

      I got the concept down independently, the various controls on the page, are going to be hooked up to the jQuery Ajax process, and we’ll be able to remove the UpdatePanels.
      I was incorrectly assuming that to “replace UpdatePanels” that I’d need to create a similar type of beast with jQuery.


      • Dave Ward
        Feb 23 - 11:22 pm

        It depends a lot on the type of beast that you need to replace. In most cases, you can replace ASP.NET WebForms server-side controls with jQuery calls for data and then use client-side templating to render that data without any postbacks, viewstate, page life cycle, etc.

        If you haven’t seen them, I have several posts about various approaches to doing that. These are a few of them (with some overlap between the two searches):

  115. [...] just read a great article by Dave Ward on about the disadvantages of using ASP.NET UpdatePanels. The article [...]

  116. [...] Panel: not hard to implement but I suggest you to read Dave Ward’s blog – Why ASP.NET AJAX UpdatePanels are dangerous and have more understand on how it works before you consider to implement [...]

  117. Megan
    Jan 14 - 2:05 am

    Hi Dave,
    I’m a beginner in ASP.NET and am having problem with buttons and stuff. My google research recommend to use updatepanel but i think i may use 10 per page. What can you suggest? Thanks!

    • Dave Ward
      Jan 15 - 4:05 pm

      Personally, I probably wouldn’t use an UpdatePanel for anything these days. Using a purely client-side (i.e. JavaScript approach) is so much more flexible and performs better.

Leave a Reply

Mobile Theme