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!