In the days of client/server applications the amount of data sent “over the wire” was not typically a huge concern unless the data was very big. This is because client/server applications typically run on local networks with 10, 100 or even 1000 Mbps connections; plenty of speed for most data applications. In the web world, however, more people access their application over remote networks, like from remote offices, home, or Starbucks. These are typically much slower connections, have to go thru many routers along the way (called “hops”), and often travel thru VPNs which encrypt/decrypt the data along the way.

On the one hand, web based system generally only send what the client needs to view the information, after processing the data, and not all of the raw data that client/server apps pass back and forth. On the other hand, the amount of data sent across the wire has a very direct impact on the speed of page loads and the like in a web application.

In the web world the amount of information sent across the wire per page is called “page weight”. Page weight is the size of the HTML, in Kbytes and also typically includes the size of the files referenced on the page (e.g., the graphics, CSS style sheets, JavaScript files, etc.). Since the referenced files are usually cached on the client they are really less of an issue than the actual page size, but still something to consider, especially for infrequent users of the system.

The good news is that you can speed up performance for remote users by just making the pages and resources smaller. And, this can be done with little or no changes to the code of the web application.

Here are 3 methods (in bang-for-the-buck order) to make significant speed gains for remote users.

1. Compress the files as they are sent from the server. This is the biggest, easiest gain. IIS has built in the ability to compress (gzip) the files it sends to the browser on the fly. Typically HTML, CSS and JS files will compress around 80% to 1/5 the original size (images don’t compress of course). Modern browsers will unzip on the fly to bring them back to their normal state for viewing. Even though you have the zip/unzip overhead added it is far outweighed by the savings in the number of bytes being transmitted over a slower connection or a long haul for larger files. Here is a great article on how to set this up with just web server configuration changes:

   http://www.dotnetjunkies.com/HowTo/16267D49-4C6E-4063-AB12-853761D31E66....

2. Put less data in the pages in the first place. ASP.NET adds a thing called view state or page state to every page. This is data that stores information about the state the page is in for the server to use when you post the page back. On some pages, the view state can get very large and therefore makes the page weight very large. Reducing the total view state size by eliminating it in parts of the page where it is not needed is something that developers can do to minimize this, but that means significant code changes. An easier, after-the-fact solution is to modify the application to store the view state on the server rather than sending it to the client. Like compression, storing the view state on the server can add some overhead to processing each page. However, this overhead can pale in comparison to the savings the client sees when not sending the view state across the wire. Here are a few articles on different methods for storing view state on the server. Warning, while this can be done without modifying the applications source code, it does take developer skills:

   Store view state in the session (memory):
   http://msdn2.microsoft.com/en-us/library/aa479403.aspx

   Store view state on the server file system:
   http://aspnet.4guysfromrolla.com/articles/011707-1.aspx

   In either case, be sure to check out the method for doing this without changing the application code by using a Page Adapter, here:
   http://msdn2.microsoft.com/en-us/library/system.web.ui.pagestatepersister(vs.80).aspx

3. Remove whitespace from the files – AKA Minifying. HTML, JavaScript, and CSS actually need very little whitespace to be processed correctly by the browser. Developers add a bunch to make them readable to the humans maintaining them. However, it is fairly common practice in the web world to remove whitespace to the minimum when going to a production web server. This process is called “minifying” or “minification” and it leaves the files totally machine readable, though difficult for humans to read. There are tools that will do this to the code after the fact and they can make a big difference. However, if compression is implemented (as in item 1 above), this one gives a bit less of a benefit because whitespace compresses very well. Here is a great tool for minifying JavaScript, free from Yahoo!, along with a more in-depth discussion on the subject:

   http://www.julienlecomte.net/blog/2007/08/13/introducing-the-yui-compres...

Any one of these solutions will give a significant performance boost to remote users and they can be combined to give even bigger benefits. If you have any users who access your web application or website remotely I strongly recommend adding one or more of these enhancements to your sites.