Compressing web content with gzip (GNU zip) is a rather old technology. Its essence boils down to the fact that before sending the content to the user, the web content is compressed using the well-known zip algorithm. The gzip specification itself is described in RFC1952 , version 4.2 of which dates from May 1996. Today, all popular browsers and web servers support web content compression using gzip. In this article I will try to talk about several ways to include gzip-compression support in asp.net projects.

Enable HTTP compression on IIS server

The first way is the easiest. You just click a couple of buttons in the IIS settings, and now the web server provides you with automatic compression for clients that gzip supports.

, , IIS , : IIS « » «».


This method is the easiest, but at the same time not the most flexible.
Pluses of such inclusion of compression:
• simplicity;
• support for IIS compression of static files;
• support for caching compressed files;
• does not require writing code.

Cons of enabling compression on IIS:
• server decides: you will not know what, when and how it is compressed;
• global enable: compression is enabled for the entire service at once and will affect all nodes or virtual directories of your server (at least, you cannot disable compression at a specific node via a gui);
• problems: I personally ran into a problem when one of the users complained that he started displaying an empty main page just after the compression was turned on via IIS, after shutdown everything returned to normal. This moment is more likely from the category of private and to the general case does not fit, but I cited it as an example of why the global inclusion of compression in IIS may not suit you.
')

Application_BeginRequest

The essence of this method, described in the Internet in many sources, for example, here

www.stardeveloper.com/articles/display.html?article=2007110401&page=1

is that you, using the System.IO.Compression.GZipStream and System.IO.Compression.DeflateStream classes that appeared in the .net framework 2.0, define your own content filter of the http request that, before sending to the client, compresses the data using GZipStream methods . The peculiarity of this method is that all actions on content compression are performed in global.asax in the Application_BeginRequest method, which is called before a user request. Thus, you can create a filter for any user request to send the entire Response content in a compressed form. Here is how this method looks as it is (taken from the site indicated above):

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

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

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

acceptEncoding = acceptEncoding.ToLower ();

if (acceptEncoding.Contains ( "gzip" ))
{
// gzip
app.Response.Filter = new GZipStream (prevUncompressedStream,
CompressionMode.Compress);
app.Response.AppendHeader ( "Content-Encoding" ,
"Gzip" );
}
else if (acceptEncoding.Contains ( "deflate" ))
{
// defalte
app.Response.Filter = new DeflateStream (prevUncompressedStream,
CompressionMode.Compress);
app.Response.AppendHeader ( "Content-Encoding" ,
"Deflate" );
}
}
</ script> This code was highlighted with Source Code Highlighter .

The main advantages of this method:
• location in global.asax allows you to solve the problem centrally, at the same time allowing compression for the entire data stream in the context of a single asp.net web application;
• almost all content is compressed;
• slightly altering this code, you can flexibly filter the contents for compression.
Cons of this method:
• the method determines the rule for the entire application; there is no possibility to disable compression for a number of pages;
• this method does not work correctly with ajax.net, which does not allow using it in an ajax-oriented application;
• compared to the first method through IIS, here you have to write code and accompany it.

It should be noted that the problem with ajax.net may have a solution, but at the time of this writing, this solution is not known to me. I will be grateful if someone describes the implementation of this method of including gzip in ajax.net projects.

Gzipencodepage

Excellent specialist Rick Strahl on his blog

west-wind.com/WebLog/default.aspx

provides another, alternative way to compress web pages through gzip. Consider a couple of functions that he wrote, and I made static:

public static bool IsGZipSupported ()
{
string AcceptEncoding = HttpContext .Current.Request.Headers [ "Accept-Encoding" ];
if (! string .IsNullOrEmpty (AcceptEncoding) &&
(AcceptEncoding.Contains ( "gzip" ) || AcceptEncoding.Contains ( "deflate" )))
return true ;
return false ;
}

public static void GZipEncodePage ()
{
if (IsGZipSupported ())
{
HttpResponse Response = HttpContext .Current.Response;

string AcceptEncoding = HttpContext .Current.Request.Headers [ "Accept-Encoding" ];
if (AcceptEncoding.Contains ( "gzip" ))
{
Response.Filter = new System.IO.Compression.GZipStream (Response.Filter,
System.IO.Compression.CompressionMode.Compress);
Response.AppendHeader ( "Content-Encoding" , "gzip" );
}
else
{
Response.Filter = new System.IO.Compression.DeflateStream (Response.Filter,
System.IO.Compression.CompressionMode.Compress);
Response.AppendHeader ( "Content-Encoding" , "deflate" );
}
}
}
* This source code was highlighted with Source Code Highlighter .

The first method simply checks the client’s support for the compression technology, while the second one is obviously almost equivalent to the method from the Example about Application_BeginRequest, only in this case it is a separate function. What does this give? Well, first, consider using:

protected void Page_Load ( object sender, EventArgs e)
{
HtmlUtil.GZipEncodePage ();
} * This source code was highlighted with Source Code Highlighter .

Obviously, this method works at the level of user pages. It works only with the body of the page and does not handle js, css and any other files.

Advantages of this approach:
• works at the level of one page, allows you to enable compression only on those pages where it is required;
• does not compress anything but the body of the page, thereby not conflicting with ajax.net.
Minuses:
• it is not possible to enable compression all over the site at once;
• does not compress js, css and other resources;
• it is necessary to write code and maintain it.

It is very important, when using this method, to call it before any first entry in the Response.

Afterword

Personally, I stopped at the third option. First of all, a part of my project was written on ajax.net and the second option did not work for me. Secondly, I ran into a problem when turning on centralized compression at the IIS level, therefore, the first option did not suit me. Thirdly, the third approach personally seems to me elegant and flexible. For js and css, you can search for other methods, and the compression of aspx alone already gives a noticeable gain in traffic.

I will give some data:
• according to my measurements, the size of these pages transmitted to the client during compression through gzip decreased on average by six times;
• the size of ajax-responses to the client has decreased on average by ten times;
• I do not undertake to estimate the load on the processor on the server, but on the Internet it is estimated as ~ 5%, which I consider quite acceptable for myself.

For myself, I conclude that the compression of pages alone can significantly reduce the size of the transmitted data, and for an ajax-oriented project, the bonus will also decrease the size of all ajax-data transmitted to the client.