arrow26 Comments
  1. Ira
    Apr 23 - 7:29 am

    You’re right on the money with this one. I will be there NOT maintaining it with you. :)

  2. [...] Why You Should Not Place Your Whole Site in an UpdatePanel (Dave Ward) [...]

  3. Siderite
    Apr 24 - 3:18 am

    It seems to me that you are going towards an MVC approach with this one, since you compare an UpdatePanel postback to a href link click. Shouldn’t you compare it to a normal postback?

    I have been working (and finished yesterday, go figure) a little Response.Filter that allows the server to only send the diff content from the previous UpdatePanel render, thus achieving compression from 50% to 98%! This would have been impossible with a normal render, since the browser loses any and all information about previous actions.

    What I do agree with is that the ViewState is a troublesome thing, moving back and forth from server to client. But for that I use a SessionViewStatePersister. I don’t know whether that presents problems of its own, but it kept the ViewState from my html so far.

    And, of course, having an UpdatePanel on the whole single page and juggling with user controls might be a little complicated and a maintainance nightmare, but it does present advantages, especially in an ASP.Net context which already provided the MasterPage and then MasterPages in other MasterPages, proving the pattern is being used a lot.

    I totally agree with the usability thing. But what can you do? Browsers and their users have been growing on each other for years, while the UpdatePanel and the ubiquitous Ajax are fairly recent developments. Should we go back to PHP/ASP days and control every single content byte?

    • Dave Ward
      Apr 24 - 11:36 am

      Keep in mind that this is specifically regarding site navigation. I wouldn’t suggest using a traditional postback for site navigation any more than using partial postbacks.

      There are always exceptions, but you generally shouldn’t find yourself loading every new content page with a POST.

      • Siderite
        Apr 25 - 12:08 am

        I agree with you on that one, but grudgingly. I kind of like the UpdatePanel and the Ajax update thing, not for performance, but for the feel of it. I always feel I am losing something when I do a normal link transfer. I wish I had a pattern that would allow for both easy navigation and SEO, but also handled everything with Ajax.

        I did encounter situations where the UpdatePanel postback was up to two times slower than a normal postback, because of the Internet Explorer local rendering.

  4. Bryan
    Apr 24 - 10:38 am

    I’ve found that combining jquery with a ScriptService is the best way to go. Throw in the new ASP.Net MVC Framework, disregard the Ajax Extensions and AjaxControlToolkit and you’re good to go.

  5. Slava
    Apr 29 - 11:32 am

    Thanks for the nice article.

    Regarding this comment…
    “The ASP.NET AJAX framework parses out the specific HTML section(s) that will be sent back to refresh the UpdatePanel(s) affected by the partial postback.”

    Q: When, why in Firebug, I see in XHR Response entire page’s HTML content including the VIEWSTATE?

    Assuming that I have a label inside the UpdatePanel, when XHR is initiated, entire page’s VIEWSTATE is sent, but in XHR Response in Firebug, I see again the entire page’s VIEWSTATE + HTML content (and not just my label)?

    • Dave Ward
      Apr 29 - 11:47 am

      The entire contents of the UpdatePanel will be refreshed during a partial postback, not only the specific elements that have changed. So, you’ll see all of the HTML contained in a refreshing UpdatePanel come back in the response to the XHR.

      You’re right about the full ViewState. The ViewState is atomic. So, it must be transmitted in full, up and back down.

      • Slava
        Apr 29 - 2:20 pm

        Strange… but what I see in the Firebug’s Response tab is the content of the entire page! not just the content of UpdatePanel. What’s the point to sent the HTML content + VIEWSTATE of the entire page, if the callback was initiated only from the UpdatePanel?

        Basically what I see when debugging the app using Firebug is that the whole page’s content is submitted and returned!! back when using UpdatePanel, + the VIEWSTATE.

        Maybe it’s something wrong with the Firebug :) ?

        • Dave Ward
          Apr 29 - 2:29 pm

          Make sure you’re looking at the console tab. If you expand a partial postback’s POST entry there, you should see a request that’s very similar to a regular postback and then a response that’s a pipe delimited string intended for the PageRequestManager.

          If you’re seeing a response of the entire page’s HTML, you’re seeing a regular postback’s response (or the response from a GET).

          • Josh
            Aug 28 - 9:22 am

            can you explain more about this? I have been wondering this myself, looking at firebug, under net, it shows the full page again in its original form, but under console I see just the content for the update panel… which is really happening, and why does firebug show the full html page if it’s only supposed to be getting the updated content?

            • Dave Ward
              Aug 29 - 7:59 am

              Just the content for the UpdatePanel is correct. In a partial postback, you should see a pipe (|) delimited string that includes the rendered HTML for the UpdatePanel’s <div>, which UpdatePanel(s) are to be updated, JavaScript registered through the ScriptManager, etc.

  6. [...] Why you should not place your whole site in an UpdatePanel [...]

  7. Rune
    May 06 - 6:08 pm

    I agree with you that updatepanel is not a great solution from a performance og user experience point of view. However, it seem to solve the problem of maintaining a “temporary” version of larger forms while at the same time doing constraint checks in the database. This could of course be handled by a javascript/webmethod combination, but then you loose the advantages of managed code.

    On the other hand it does almost take your breath away when you see the complete javascript-json-webmethod combination used to the fullest like the controls from… componentart (I think they’re called). The performance is almost desktop-like but you have to write all your controls in javascript which must take a lot longer to do.

    • Anonymous
      May 08 - 8:37 am

      “but you have to write all your controls in javascript which must take a lot longer to do”

      Totally agree. The point of Javascript JSON WebMethod is to archive the functionality of true AJAX application, not a simulation like with UpdatePanel :). BUT! And that “BUT” is the cornerstone. It would be a real nightmare to built manually the Javascript AJAX UI library by hand. Everyone I know decided to use Javascript AJAX libraries available now even for free, such as ExtJS, wich is FULL of any UI elements you might ever need to built your app. So what would be the reason for me to choose ASP.NET AJAX via WebServices?

      • Slava
        May 08 - 9:15 am

        Sorry, achieve, not archive :)

  8. i try to place my controls in several update it somehow better?
    i now that using trigger is better but it requires many thinking and i am somehow lazy! ;)

  9. Shalan
    Oct 21 - 7:24 am

    Great, insigthful article!

    One question though…I had no idea about content in an updatePanel not beign able to be indexed by crawlers!! I have on one of my sites an UpdatePanel that contains the main bulk of that page’s text (stored in DB). I am delay-loading this so that the rest of the page loads first and fast, and I display a nice loading image to the user.

    What would you recommend be an alternative to achieving this without using Updatepanel?? would the same SEO concerns arise if I use a Page Method instead?


    • Dave Ward
      Oct 21 - 12:05 pm

      A page method or web service will have the same issues with SEO.

      For public facing sites, where SEO is important, you should generally avoid locking content in AJAX functionality. Use it to progressively enhance the UI, but not as the foundation of the UI.

      In your case, is the delay loaded content something that can be cached instead?

      If not, an alternative is to use user-agent sniffing to deliver a static page only to the spiders.

  10. Shalan
    Oct 28 - 3:25 am

    I have seen this in action on some popular local websites in my country, where the navigation and css loads first and a nice loading gif shows in the centre whilst the page content is being fetched. If i search their site in Google for specific content, the results still show. But I agree with you…I rather have my content indexed.

    Yes, the content can be cached and it is for a public facing site. Its actually for the main content block of my CMS. Im basically doing a select query based on the querystring (viz url rewriting) and binding the result to a literal control. I just thought that I could load the rest of my page, and then load this content last.

    I’m not sure where I heard this, but I’m led to believe that providing alternative pages purely for bots is a no-no.


  11. sam
    Jan 02 - 10:56 pm

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

    What are your thoughts on uframes:



    • Dave Ward
      Jan 02 - 11:46 pm

      I wouldn’t use it for navigation.

  12. John
    Aug 10 - 4:18 pm

    Just a thought, but when talking about the source control and having 1 person lock everyone else in a single page site… that is true, and a problem.. however, couldn’t that easily be circumvented by the main page being the navigation or sorts and the actual content of the single page app being comprised of individual user controls that they could be checked out as needed in a multi-developer environment?

  13. João Rosa
    Sep 16 - 5:45 am

    After reading this post (and another across the web), I’ve a question.
    If I want to have async requests in my web site, it’s better to user an webservice (or WCF), instand using an updatepanel, because the charge in the server and slow down performance?
    I’ve read the post Why ASP.NET AJAX UpdatePanels are dangerous, and my sensation is to use the service… But the security concerns?

    Thanks in advance.

    • Dave Ward
      Sep 16 - 8:31 am

      Yes, if performance matters to you, services are the way to go. Security is something you should always keep in mind, but web services can be secured in the same way that ASPX pages can. So, security is no more or less an issue with the service-based approached.

Leave a Reply

Mobile Theme