i-Vertys Blog!

Enabling Gzip and Deflate HTTP Compression in ASP.NET pages

The output of most ASP.NET pages is in the form of text. In the terms of HTTP, the content-type is called “text/html”. The text received by the client browser, from the ASP.NET page on an IIS Web Server, is then rendered on your computer screen. Since this communication takes place over the internet, it consumes bandwidth. For instance, a 40 KB ASP.NET page will take exactly 40 KB of network bandwidth (plus the bandwidth for headers sent and received by the client browser). To optimize this communication cycle, HTTP Gzip and Deflate compression is used. HTTP compression will enable a 40 KB output from an ASP.NET page to be compressed using Gzip or Deflate compression to as low as 12-15 KB, thus saving 25-28 KB of network bandwidth. Now consider the implications of this network bandwidth savings over hundreds of thousands of requests handled by IIS Server each day. This can be huge? Isn’t it? Add to this the fact that to the users accessing your website, your website will load faster and will thus improve the user experience and perception of your website.

How to enable HTTP Compression in our ASP.NET pages?
Now that you understand, how important HTTP compression can be for your website and its visitors, we will discuss what is required to achieve HTTP Gzip and Deflate compression in our ASP.NET websites. The first thing that you should know is that HTTP compression is of two types, it can be Gzip or Deflate. To use HTTP compression in our ASP.NET pages without editing every single one of them, we will make use of ASP.NET web application life cycle events in Global.asax file.

A Global.asax file is placed in your ASP.NET application folder. It can contain methods to handle ASP.NET web application life cycle events. The names and details of all web application events that we can handle in Global.asax file is beyond the scope of this tutorial. But one event that we will handle and where we will insert our code is PreRequestHandlerExecute. It occurs just before ASP.NET starts executing an event handler. The complete method signature to handle this event is displayed below:

void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
	...
}

Global.asax

Ok folks, let’s cut the details and go straight to the code. If your ASP.NET web application doesn’t already contain a Global.asax file, create a new one using notepad. Then insert following code in it:

<%@ Application Language="C#" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System.IO.Compression" %>

<script runat="server">
void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
	HttpApplication app = sender as HttpApplication;
	string acceptEncoding = app.Request.Headers["Accept-Encoding"];
	Stream prevUncompressedStream = app.Response.Filter;

	if (!(app.Context.CurrentHandler is Page) ||
		app.Request["HTTP_X_MICROSOFTAJAX"] != null)
		return;

	if (acceptEncoding == null || acceptEncoding.Length == 0)
		return;

	acceptEncoding = acceptEncoding.ToLower();

	if (acceptEncoding.Contains("deflate") || acceptEncoding == "*")
	{
		// defalte
		app.Response.Filter = new DeflateStream(prevUncompressedStream,
			CompressionMode.Compress);
		app.Response.AppendHeader("Content-Encoding", "deflate");
	} else if (acceptEncoding.Contains("gzip"))
	{
		// gzip
		app.Response.Filter = new GZipStream(prevUncompressedStream,
			CompressionMode.Compress);
		app.Response.AppendHeader("Content-Encoding", "gzip");
	}
}
</script>

Explanation
Guys, the above code is all that is required to enable HTTP compression in your ASP.NET pages. This is true, pretty simple stuff. Let us now focus on the details of the code presented above.

The first thing we do is to tell the ASP.NET compiler that the forthcoming code is going to be in the language, C#.

<%@ Application Language="C#" %>

Next, we import the namespaces that our code will make use of. Remember, the GZipStream and DeflateStream classes are new in ASP.NET 2.0 and are present in the System.IO.Compression namespace.

<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System.IO.Compression" %>

Next, we declare the method that will handle the PreRequestHandlerExecute life cycle event. As explained earlier, this event occurs just before ASP.NET starts executing an event handler.

void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
	...
}

Next, we properly cast the sender Object, using the as keyword, into a variable of type HttpApplication, because this is the object that fired this event to begin with. Using this object, we fetch the headers collection sent by the client-browser. Specifically, we are interested in a “Accept-Encoding” header. If a client browser supports compressed content streams (which most browsers do) of the types, Gzip and Deflate, the value of this header will contain them. A reference to current uncompressed output Stream object used by ASP.NET to send the plain text (or binary) output to the client browser is saved in the prevUncompressedStream object.

We try to make sure that the requested ASP.NET resourse is a valid ASP.NET page. If it is not, then we return and do nothing. Addionally, we also check for “HTTP_X_MICROSOFTAJAX” item in the HttpRequest collection. This item is often present when using AJAX in ASP.NET pages. When the ASP.NET content is compressed when AJAX is being used, the page can throw exceptions. So we play safe, and don’t compress the page if AJAX is being used.

Finally, we check to see if either the client browser did not send the “Accept-Encoding” header, or if it did send, but its value is empty, will mean that client-browser cannot process compressed content. In that case, we simply return from this method and do nothing

	HttpApplication app = sender as HttpApplication;
	string acceptEncoding = app.Request.Headers["Accept-Encoding"];
	Stream prevUncompressedStream = app.Response.Filter;

	if (!(app.Context.CurrentHandler is Page) ||
		app.Request["HTTP_X_MICROSOFTAJAX"] != null)
		return;

	if (acceptEncoding == null || acceptEncoding.Length == 0)
		return;

We then set the case of all the characters in the acceptEncoding header’s value to lower case. We do this so that when we attempt to compare the presence of strings like “gzip” and “deflate” in the acceptEncoding variable, values like “GZIP”, “gZiP”, and “Gzip” will be interpreted as one and the same.

	acceptEncoding = acceptEncoding.ToLower();

Finally, we search the acceptEncoding header for the “deflate” value. If present, we create a new DeflateStream object and set the Respone.Filter property to this value. This will mean that all the calls to Response.Write() in the ASP.NET code will actually access the DeflateStream object, and the output will thus get compressed. Next, we also set (or add) the outgoing header “Content-Encoding” with the value of “deflate” to indicate to the client browser that the content encoding is going to be Deflate compressed so that it will have to decompress it at the client-side.

Lastly, if the client-browser does not support “deflate” stream but supports the “gzip” stream, we make use of GZipStream object in place of DeflateStream object.

	if (acceptEncoding.Contains("deflate") || acceptEncoding == "*")
	{
		// defalte
		app.Response.Filter = new DeflateStream(prevUncompressedStream,
			CompressionMode.Compress);
		app.Response.AppendHeader("Content-Encoding", "deflate");
	} else if (acceptEncoding.Contains("gzip"))
	{
		// gzip
		app.Response.Filter = new GZipStream(prevUncompressedStream,
			CompressionMode.Compress);
		app.Response.AppendHeader("Content-Encoding", "gzip");
	}

That’s all guys. Now make the changes described above and access an ASP.NET page in your website. This time the page will be Deflate HTTP compressed and will load quickly.

For further assistance between Gzip and Deflate please refer this link,

http://www.stardeveloper.com/articles/display.html?article=2008111201&page=1

There are certain things you should take into account when you are developing your applications. Below are top 20 tips to improving ASP.net application Performance.

1. Disable Session State
   Disable Session State if you’re not going to use it.  By default it’s on. You can actually turn this off for specific pages, instead of for every page:

   <%@ Page language="c#" Codebehind="WebForm1.aspx.cs"
   AutoEventWireup="false" Inherits="WebApplication1.WebForm1"
   EnableSessionState="false" %>

   You can also disable it across the application in the web.config by setting the <sessionState> mode value to Off.

2. Output Buffering
   Take advantage of this great feature.  Basically batch all of your work on the server, and then run a Response.Flush method to output the data.  This avoids chatty back and forth with the server.

   <%response.buffer=true%>

   Then use:

   <%response.flush=true%> 

3. Avoid Server-Side Validation
   Try to avoid server-side validation, use client-side instead. Server-Side will just consume valuable resources on your servers, and cause more chat back and forth.
4. Repeater Control Good,  DataList, DataGrid, and DataView controls Bad
   Asp.net is a great platform, unfortunately a lot of the controls that were developed are heavy in html, and create not the greatest scaleable html from a performance standpoint.  ASP.net  repeater control is awesome!  Use it!  You might write more code, but you will thank me in the long run!
5. Take advantage of HttpResponse.IsClientConnected before performing a large operation:

   if (Response.IsClientConnected)
   {
   // If still connected, redirect
   // to another page. 
   Response.Redirect("Page2CS.aspx", false);
   }

   What is wrong with Response.Redirect? Read on…

6. Use HTTPServerUtility.Transfer instead of Response.Redirect
   Redirect’s are also very chatty.  They should only be used when you are transferring people to another physical web server.  For any transfers within your server, use .transfer!  You will save a lot of needless HTTP requests.
7. Always check Page.IsValid when using Validator Controls
   So you’ve dropped on some validator controls, and you think your good to go because ASP.net does everything for you!  Right? Wrong!  All that happens if bad data is received is the IsValid flag is set to false. So make sure you check Page.IsValid before processing your forms!
8. Deploy with Release Build
   Make sure you use Release Build mode and not Debug Build when you deploy your site to production. If you think this doesn’t matter, think again.  By running in debug mode, you are creating PDB’s and cranking up the timeout.  Deploy Release mode and you will see the speed improvements.
9. Turn off Tracing
   Tracing is awesome, however have you remembered to turn it off? If not, make sure you edit your web.config and turn it off!  It will add a lot of overhead to your application that is not needed in a production environment.

   <configuration>
   <system.web>
   <trace enabled="false" pageOutput="false" />
   <trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true"/>
   <compilation debug="false" />
   </system.web>
   </configuration>

10. Page.IsPostBack is your friend
    Make sure you don’t execute code needlessly. I don’t know how many web developers forget about checking IsPostBack!  It seems like such a basic thing to me!  Needless processing!
11. Avoid Exceptions
    Avoid throwing exceptions, and handling useless exceptions. Exceptions are probably one of the heaviest resource hogs and causes of slowdowns you will ever see in web applications, as well as windows applications.  Write your code so they don’t happen!  Don’t code by exception!
12. Caching is Possibly the number one tip!
    Use Quick Page Caching and the ASP.net Cache API!  Lots to learn, its not as simple as you might think.  There is a lot of strategy involved here.  When do you cache?  what do you cache?
13. Create Per-Request Cache
    Use HTTPContect.Items to add single page load to create a per-request cache.
14. StringBuilder
    StringBuilder.Append is faster than String + String.  However in order to use StringBuilder, you must

    new StringBuilder()

    Therefore it is not something you want to use if you don’t have large strings.  If you are concatenating less than 3 times, then stick with String + String. You can also try String.Concat

15. Turn Off ViewState
    If you are not using form postback, turn off viewsate, by default, controls will turn on viewsate and slow your site.

    public ShowOrdersTablePage()
    {
    this.Init += new EventHandler(Page_Init);
    }
    
    private void Page_Init(object sender, System.EventArgs e)
    {
    this.EnableViewState = false;
    }

16. Use Paging
    Take advantage of paging’s simplicity in .net. Only show small subsets of data at a time, allowing the page to load faster.  Just be careful when you mix in caching.  How many times do you hit the page 2, or page 3 button?  Hardly ever right!  So don’t cache all the data in the grid! Think of it this way: How big would the first search result page be for “music” on Google if they cached all the pages from 1 to goggle
17. Use the AppOffline.htm when updating binaries
    I hate the generic asp.net error messages!  If I never had to see them again I would be so happy.  Make sure your users never see them!  Use the AppOffline.htm file!
18. Use ControlState and not ViewState for Controls
    If you followed the last tip, you are probably freaking out at the though of your controls not working.  Simply use Control State.  Microsoft has an excellent example of using ControlState here, as I will not be able to get into all the detail in this short article.
19. Use the Finally Method
    If you have opened any connections to the database, or files, etc, make sure that you close them at the end!  The Finally block is really the best place to do so, as it is the only block of code that will surely execute.
20. Option Strict and Option Explicit
    This is an oldy, and not so much a strictly ASP.net tip, but a .net tip in general.  Make sure you turn BOTH on.  you should never trust .net or any compiler to perform conversions for you.  That’s just shady programming, and low quality code anyway.  If you have never turned both on, go turn them on right now and try and compile.  Fix all your errors.

Please refer the following link as well.

http://msdn.microsoft.com/en-us/library/ms973839.aspx

Before you try to add your site to the search engines, you should understand what they look for when they decide how to rank your site. Just because you’re listed doesn’t mean you’ll get traffic.  You have to make sure your site is search engine ready.

The general rule of thumb is that most engines use a “formula” to determine keyword relevancy. The technical term is called an “algorithm”, and each search engine has its own unique algorithm that it uses to rank pages.

Generally, this magic formula consists of your page title, overall body content and the number and quality of links pointing back to your site, how long people stay on your site, etc.

It’s important to note that every engine is different. Some may look at inbound links (number of people linking to you), others may place more  emphasis on your body content.  These days, meta tag content is becoming less and less important.

Because of abuse, many search engines no longer use these tags to help rank pages, but you should still include them because they do use them to display information about your site.Don’t stress out over the meta tags. You should definitely use them on every page. Just understand that how well you rank depends on how popular your site becomes over time.

There are a handful of engines out there that bring traffic, but the reality is a very large percentage of search engine traffic comes from Google, Yahoo and MSN.  Yes, there are other engines like AOL, Netscape etc., but they pull their results from the Big 3.

So in other words, once you start getting traffic from Google, Yahoo and MSN, you’ll rank well in the others automatically.

To calculate the PageRank for a page, all of its inbound links are taken into account. These are links from within the site and links from outside the site.

PR(A) = (1-d) + d(PR(t1)/C(t1) + … + PR(tn)/C(tn))

That’s the equation that calculates a page’s PageRank. It’s the original one that was published when PageRank was being developed, and it is probable that Google uses a variation of it but they aren’t telling us what it is. It doesn’t matter though, as this equation is good enough.

In the equation ‘t1 - tn’ are pages linking to page A, ‘C’ is the number of outbound links that a page has and ‘d’ is a damping factor, usually set to 0.85.

We can think of it in a simpler way:-

a page’s PageRank = 0.15 + 0.85 * (a “share” of the PageRank of every page that links to it)

“share” = the linking page’s PageRank divided by the number of outbound links on the page.

A page “votes” an amount of PageRank onto each page that it links to. The amount of PageRank that it has to vote with is a little less than its own PageRank value (its own value * 0.85). This value is shared equally between all the pages that it links to.

From this, we could conclude that a link from a page with PR4 and 5 outbound links is worth more than a link from a page with PR8 and 100 outbound links. The PageRank of a page that links to yours is important but the number of links on that page is also important. The more links there are on a page, the less PageRank value your page will receive from it.

If the PageRank value differences between PR1, PR2,…..PR10 were equal then that conclusion would hold up, but many people believe that the values between PR1 and PR10 (the maximum) are set on a logarithmic scale, and there is very good reason for believing it. Nobody outside Google knows for sure one way or the other, but the chances are high that the scale is logarithmic, or similar. If so, it means that it takes a lot more additional PageRank for a page to move up to the next PageRank level that it did to move up from the previous PageRank level. The result is that it reverses the previous conclusion, so that a link from a PR8 page that has lots of outbound links is worth more than a link from a PR4 page that has only a few outbound links.

Whichever scale Google uses, we can be sure of one thing. A link from another site increases our site’s PageRank. Just remember to avoid links from link farms.

Note that when a page votes its PageRank value to other pages, its own PageRank is not reduced by the value that it is voting. The page doing the voting doesn’t give away its PageRank and end up with nothing. It isn’t a transfer of PageRank. It is simply a vote according to the page’s PageRank value. It’s like a shareholders meeting where each shareholder votes according to the number of shares held, but the shares themselves aren’t given away. Even so, pages do lose some PageRank indirectly, as we’ll see later.

Ok so far? Good. Now we’ll look at how the calculations are actually done.

For a page’s calculation, its existing PageRank (if it has any) is abandoned completely and a fresh calculation is done where the page relies solely on the PageRank “voted” for it by its current inbound links, which may have changed since the last time the page’s PageRank was calculated.

The equation shows clearly how a page’s PageRank is arrived at. But what isn’t immediately obvious is that it can’t work if the calculation is done just once. Suppose we have 2 pages, A and B, which link to each other, and neither have any other links of any kind. This is what happens:-

Step 1: Calculate page A’s PageRank from the value of its inbound links

Page A now has a new PageRank value. The calculation used the value of the inbound link from page B. But page B has an inbound link (from page A) and its new PageRank value hasn’t been worked out yet, so page A’s new PageRank value is based on inaccurate data and can’t be accurate.

Step 2: Calculate page B’s PageRank from the value of its inbound links

Page B now has a new PageRank value, but it can’t be accurate because the calculation used the new PageRank value of the inbound link from page A, which is inaccurate.

It’s a Catch 22 situation. We can’t work out A’s PageRank until we know B’s PageRank, and we can’t work out B’s PageRank until we know A’s PageRank.

Now that both pages have newly calculated PageRank values, can’t we just run the calculations again to arrive at accurate values? No. We can run the calculations again using the new values and the results will be more accurate, but we will always be using inaccurate values for the calculations, so the results will always be inaccurate.

The problem is overcome by repeating the calculations many times. Each time produces slightly more accurate values. In fact, total accuracy can never be achieved because the calculations are always based on inaccurate values. 40 to 50 iterations are sufficient to reach a point where any further iterations wouldn’t produce enough of a change to the values to matter. This is precisiely what Google does at each update, and it’s the reason why the updates take so long.

One thing to bear in mind is that the results we get from the calculations are proportions. The figures must then be set against a scale (known only to Google) to arrive at each page’s actual PageRank. Even so, we can use the calculations to channel the PageRank within a site around its pages so that certain pages receive a higher proportion of it than others.

There are an unlimited number of ways to accumulate IBL or backlinks. Here are the four most common ways:

1. List your site in as many Directories as possible
2. Engage in a reciprocal linking campaign
3. Buy backlinks
4. Write newsletters or articles and get them published on other sites or in your own blog.

Some purists advocate a fifth way of accumulating links. They maintain that if your page has enough outstanding content that people will put up links as a service to their viewers without asking for, or demanding, a link back in return. That is certainly possible for some types of sites, but is not generally a viable method for competitive commercial web sites.

Submit to Directories.

There are many directories, both paid submission and free, where you can submit your site. The most famous is probably the DMOZ directory, however be prepared for a long wait to get into this directory. Many of the other directories like GoGuides, Joeant, Gimpsy and the brand new Bluefind will charge you about $40 as a submission fee. Then of course there is Yahoo who will charge you $300 just to review your site with no guarantee of inclusion.

Depending on your market place and demographics there may be many regional, local or industry specific directories available. Some are free and others have a nominal inclusion fee.

Reciprocal Links

Let’s deal with the objection that some people have to reciprocal links. Some “experts” claim that Google devalues reciprocal links.

So how can you find people who are willing to exchange links with you? One of the simplest ways is to search in Google for your prime keywords. Then do a “search within results” for all the pages that contain “add your URL” or “add your link”. The other variation on this is to do a link: search on the top 10 or 20 pages. This will show you all the pages that link to these sites. You can then contact the webmasters of these sites and ask them to exchange links with you.

If you are really serious about reciprocal linking you may want to use some software that will help you organize and monitor your links. As part of managing a reciprocal linking program you need constantly to be checking for dead links from your site, and to verify that all the reciprocal links from other sites are up and running.

Buy Backlinks.

There are a number of sites that will sell you links. Some people are hottified at this thought, but I see no difference between buying links and online advertising. If you pay to have a banner displayed on a busy web site you are also buying a link.

It is possible to buy individual links, or to buy what are known as “run of the site” links. These are normally text links from every page on the site. An entire industry has grown up around link buying. There is an auction site dedicated exclusively to buy and selling links and there are several link brokers and re sellers on the Internet.

Anchor Text

To get the maximum return for your investment make sure that you use your prime keyword phrases as anchor text in all your IBL. This practice should even be employed with internal links. Try and exchange link with sites that are related in content and theme to your own site. This may mean that you will have to link to your competitors upon some occasions.

Articles, Newsletters etc.

If you want to have links from relevant and related pages without linking to a competitor the easiest way to accomplish this is to write an article, or a series of articles, about your industry or market niche, and link to your site from these. There are many people who are looking for, and will publish, good articles. SitePro News is one example of this. I also publish a collection of articles in my InfoPool, and am always looking for new articles and good content.

Link Building is Hard Work

There is no free lunch when it comes to link building. With the possible exception of purchasing links, accumulating and managing an aggressive linking campaign is continuous hard work. However, experience has shown that if you want to place well in the SERPs for competitive search terms you really have no other choice.