Introduction
There are several techniques available to reduce ASP.NET page output size. Today we will discuss two interesting techniques among them.
HTTP Compression
This is a cool technique to reduce page size by compressing HTTP response stream. This feature is available as a part of IIS6.0 and onwards. Generally output of ASP.NET page is in text format which travels from IIS to client browser. Don’t get disappointed, HTTP Compression features can be achieved in ASP.Net application hosted in IIS 5.1 also. Only difference is, we have to write little line of codes instead. Do the following steps in “Global.asax” to encode the page output.
Step1: Include the namespace “System.IO.Compression”
Step2: Write following function to see, whether HTTP compression is supported by client browser.
public bool IsCompressionAllowed()
{
//Browser supported encoding format
string AcceptEncoding = HttpContext.Current.Request.Headers["Accept-Encoding"];
if (!string.IsNullOrEmpty(AcceptEncoding))
{
if(AcceptEncoding.Contains("gzip") || AcceptEncoding.Contains("deflate"))
return true; ////If browser supports encoding
}
return false;
}
Step3: Add the event handler “Application_AuthenticateRequest” and write following code.
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
{
HttpResponse Response = HttpContext.Current.Response;
if (IsCompressionAllowed()) // If client browser supports HTTP compression
{
//Browser supported encoding format
string AcceptEncoding = HttpContext.Current.Request.Headers["Accept- Encoding"];
//if client browser supports both "deflate"
//and "gzip" compression, Then we will consider "deflate" first , because it is
// more efficient than "gzip"
if (AcceptEncoding.Contains("deflate"))
{
Response.Filter = new DeflateStream(Response.Filter, CompressionMode.Compress);
Response.AppendHeader("Content-Encoding", "deflate");
}
else
{
Response.Filter = new GZipStream(Response.Filter,CompressionMode.Compress);
Response.AppendHeader("Content-Encoding", "gzip");
}
}
// Allow proxy servers to cache encoded and unencoded versions separately
Response.AppendHeader("Vary", "Content-Encoding");
}
Above code will compress HTTP response based on the compression format supported by browser. Now if we run a sample application and track the http response through Fiddler, we can see that, the response has come to browser in “deflate” format. See below the screen shot.

If we remove the compression part from Global.asax and run the same application to see HTTP Response in fiddler, we will see following.

Just compare the page size. 1,765 byte vs. 106861 byte and understand how drastically the page size has come down to 1765 byte with “HTTP Compression”.
SessionPageStatePersister
ASP.NET persistence mechanism store view state data in HiddenFieldPageStatePersister class , which in turn maintain data in a hidden text box. This mechanism is well known but specially creates problem when view state is not maintained carefully. Page with larger size of view state increase the downtime and affects the performance. Using “SessionPageStatePersister” we can store viewstate in session also. Storing view state in session drastically reduces page size and expedites performance. See below the steps involved.
Step1: Create a page controller inherited from “Page” class
public class PageController : Page
{
protected override PageStatePersister PageStatePersister
{
get
{
// Store view state in session
return new SessionPageStatePersister(this);
}
}
}
Step2: Make sure all ASP.NET page must derive from above controller.
public partial class Default : PageController
{
protected void Page_Load(object sender, EventArgs e)
{
////////////
}
}
That’s all, if you browse your page and check the view state. You can see view state size has almost come down to half. Below is the view state of a page displaying 1000 records in a grid and each record is pertaining 5 columns.
<input type="hidden" id="__VIEWSTATE" alue="/wEPaA8FDzhjYzdmOTg5ZTEyZGRhYxgBBQdHcmRVc2VyDzwrAAoBCAIBZJVttOvUuwS2wCkalf3GpRmGTzHN" />
While implementing SessionPageStatePersister we must consider following points
1. Since viewstate is maintaining in session so numerous access to the application might cause memory crash.
2. Viewstate info will still persist in the memory after user logs out or leaves the page. Memory will get release when session time out occurs.