Performance Tuning: Clear hidden form variables to avoid unnecessarily large post backs #browser #html #javascript

To create rich web applications, it is fairly common to encode data in JSON on the server and then manipulate it using javascript on the client.  For example, when creating a rich Datatable in YUI, rather than rendering the data in an HTML table that will be destroyed and replaced, it can be more efficient to encode it in JSON and then let the datatable just render part of it.

To do this, you need to generate the JSON on the server and then get it down to the browser.  While you could create a separate AJAX call to do this, it means doing a second roundtrip, so a faster alternative is to hide it inside the webpage itself and retrieve it in Javascript.  Of course, you now have the problem of encoding it, making it invisible in the page, and then finding it afterwards.

Hidden input form variables are an obvious choice.  There is already logic on most web application platforms including ASP.NET to handle the encoding, and the DOM will unencode it (somehow saying “decode” doesn’t sound right) when you retrieve it using something like document.getElementById("myformvariable").value.

The performance risk here is that while you are simply using the form variable as a convenient way of sending some data from the server down to the browser, the browser doesn’t know that.  It thinks that the form data is actually needed for the next request and dutifully sends it back up to the server.  If you are sending a lot of data (like the information used in a table), it can really hurt performance.  If you look in a tool like HttpWatch, you may see this as an unusually large request size and a long transmission time:


If you look at the example above, you will see that the request actually sent more data than was received.  You also see that almost a third of the time was spent just sending up the request to the client (the bright green).  Beyond the fact that you are sending unnecessary data up, there are two factors that exacerbate the problem:

1.       Many user’s internet connections have much faster download speeds than upload speeds.  While it may be quick to send the data down, sending the same data back up is a lot slower

2.       Upstream data is not compressed by the browser.  While you can gzip the contents sent from the server, requests from the client just come in plain text.  This is why in the example above, the postback is actually larger than the subsequent response

The solution is pretty simple.  In your javascript, once you have retrieved your data, just wipe it out with document.getElementById("myformvariable").value = "".

Here is the same request with this additional line:


As you can see, the amount of data sent is now tiny, and the bright green of send time is almost invisible.  Problem solved!

This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

4 Responses to Performance Tuning: Clear hidden form variables to avoid unnecessarily large post backs #browser #html #javascript

  1. duncansmart says:

    JSON is JavaScript. Render it into tags e.g. var myData = { json…}. this also means you don’t have to eval() it, which you would do when stashing in form fields.

  2. duncansmart says:

    And here we have an example of lame input sanitisation! 🙂 That should have said “render it into [script] tags”

  3. Jeremy Rothman-Shore says:

    That’s a good tip! We’ll use that in the future.

  4. Bishnu says:

    I am using Json to display a table using YUI. My question here is, if i dont use eval() in the javascript then it is considering JSON as a string but not as a Json array. But, if i use eval() then it is returning a JSON array. Any ideas on this… Thanks,Bishnu.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s