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 name space “System.IO.Compression
Write following function to see, whether HTTP compression is supported by client browser.
public bool IsCompressionAllowed()
string AcceptEncoding = HttpContext.Current.Request.Headers"[Accept-Encoding"];
if(AcceptEncoding.Contains("gzip") || AcceptEncoding.Contains("deflate"))
return true; }
Add the event handler “Application_AuthenticateRequest
” and write following code.
protected void Application_AuthenticateRequest(Object sender, EventArgs e)
HttpResponse Response = HttpContext.Current.Response;
string AcceptEncoding = HttpContext.Current.Request.Headers["Accept-Encoding"];
Response.Filter = new DeflateStream(Response.Filter,
Response.Filter = new GZipStream(Response.Filter,CompressionMode.Compress);
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 and the entity size is 1765 byte
If we remove the compression part from Global.asax and run the same application to see HTTP Response in fiddler, we can see the output is in "No Compression" format and the entity size is 106861 byte.
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:
Add a class named PageController inherited from “Page” class.
public class PageController : Page
protected override PageStatePersister PageStatePersister
return new SessionPageStatePersister(this);
Make sure all ASP.NET page must derive from above class.
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" value="/wEPaA8FDzhjYzdmOTg5ZTEyZGRhYxgBBQdHcmRVc2VyDzwrAAoBCAIBZJVttOvUuwS2wCkalf3GpRmGTzHN" />
While implementing SessionPageStatePersister we must consider following parameters
1.Since viewstate is maintaining in session so numerous access to
the application might degrade the performance.
2.Viewstate info will still persist in the memory after user logs
out or leaves the page. Memory will get release when session time