Reducing the size of ASP.NET pages

Introduction

We all know when a page is requested, ASP.NET processes the page, its server controls, and finally sends the HTML to the client-side for the browser to render it. The time taken to download the HTML at the client side depends mainly on the final size of the page. If your page is data rich, it would take a lot of time to fetch it. So here I am presenting a technique to reduce the size of ASP.NET web pages.

Background

When you see a page's HTML source by clicking “View Source” in the browser, you could see that there are a lot of white space on the left side of each line on the HTML. This is actually a waste. Try saving the HTML page to your desktop and notice its size. Then delete all the spaces on the left side and then check its size. You could see that the size of the page reduces considerably, sometimes more than 50%!! (watch the View Source of Orkut in a browser).

Using the code

Here is a technique to achieve the same.

Create a class in App_Code that derives from the System.Web.UI.Page class.

publicclass MyPageBase : System.Web.UI.Page
{
}

Replace System.Web.UI.Page in all your web pages (.aspx.cs) with MyPageBase. This means that now all your web pages are deriving from MyPageBase.

Notes

Notice the usage of ConfigurationManager.AppSettings["OptimizeHtmlOutput"] != "0". You can define a key in the appsettings section of the web.config file to enable or disable this feature. Any value other than “0” will enable optimization.

This code works well in AJAX based applications as well. Compare the size difference and performance by changing the flag. This is very beneficial especially in pages which contain a huge amount of data.

What he provided is not an alternative solution to compression, it is how to reduce the size of the page what ever with compression or not, it is always better to minimize the size of the page as much as possible even if you are using the compression specially if wasted spaces like Tags spacing

What about 1st reduce the size with this and then use Gzip ?
Besides Gzip requires more CPU utilization both in server and client side.
On low end machines, the browser looks still loading until the data is decompressed.
And the browser's HTML parser can save some time for trimming these white spaces and extracting and needed HTML for rendering.

I cant give you high marks because this is not the best way to reduce page size.

The following two ways are the best:

1) Dont retain ViewState in the page, turn that off and retain ViewState on the server (in memory or SQL server) instead. There is an article on MSDN on how to implement this. ViewState is frequently very HUGE in .NET pages.

2) Turn on IIS HTTP compression for your web site, this is a very simple no-code-involved way to reduce page weight on the network transport. Browsers will decompress pages delivered by web servers implementing standard compression.

The method you present is really not the best approach, but nice try at solving the very important problem of page weight. .NET brought about many great changes, but retaining ViewState in the page payload was a big mistake in my opinion, fortunately there is a way to keep ViewState out of the page. It becomes especially bad when users need to HTTP POST a large page, as .NET only supports one FORM tag per page, posting all or nothing including the ViewState.

This is not a bad technique, but you can also apply the same methodology by writing a response filter and handling it within a HttpModule. That will mean that you will not need to inherit a new class for all your pages and retrofit this to existing sites.

We have also been able to move and compress the viewstate using this method.

Just to make this discussion more complete, in the IIS there are levels for gzip from 1-10. I think if you really do not want batter your cpu you can set it to low. For most people 8-9 kind of works optimally, but may be 2 or 3 will be good for the CPU's your are using.

There is another idea where like in this article your are sending the stripped version of your HTML page you can send the gzipped version, but the page it self gzipping. I think this can take care of the page output caching.