ASP.NET HTTP Compression Overview

You know GZIP compression over HTTP can reduce page size in ASP.NET, but want to look at all the factors involved. Factors such as dynamic pages and output caching need to be considered. Here we test server-side compression using GZIP in ASP.NET, using the C# programming language.

This ASP.NET article describes compression. The example C# code sends GZIP data.

Compression in ASP.NET

Here I want to use some online tools to first see how long the page takes to transfer over the wire. Often DNS lookups and other overhead can dwarf the time spent downloading the file. Is the file size truly important?

AOL Pagetest

This AOL open-source tool lets us try our page on a dialup or DSL modem in Virginia, USA. I chose to simulate the DSL connection. The content was served all from two locations in Arizona. This way I eliminated any confounding factors such as proxies and caches.

Beginning the test. The site is located at webpagetest.org, and currently it uses the IE7 browser. Next I show the site layout and how you can use it to perform a similar test, as of September 2008.

Compression algorithm speed

I developed a test console program that measures how long it takes my PC using .NET to compress a 20 KB mostly random string using GZipStream. My results showed that the process took about 2.2 milliseconds per iteration.

Alternative algorithm. You could use DEFLATE instead of GZIP for a server-side performance boost. Mads Kristensen notes that deflate performs 41% faster on an empty byte array, but my testing indicated deflate was less than 5% faster on a randomized 20 KB string. The site I found this information on is not available.

Example implementation. The following code can be used to compare GZipStream and DeflateStream. I think an even better benchmark could be used on the web pages you want to compress, so customizing this and running it yourself may be good.

Class that uses DeflateStream [C#]

using System;
using System.IO;
using System.IO.Compression;
using System.Text;

class CompressionTest
{
    public static void PerformanceTest()
    {
	//
	// Get random bytes
	//
	byte[] buffer = RandomBytes();

	long t1 = Environment.TickCount;
	using (MemoryStream stream = new MemoryStream())
	{
	    for (int i = 0; i < 1000; i++)
	    {
		// A
		// GZipStream comp = new GZipStream(stream, CompressionMode.Compress);
		// B
		DeflateStream comp = new DeflateStream(stream, CompressionMode.Compress);
		comp.Write(buffer, 0, buffer.Length);
	    }
	}
	long t2 = Environment.TickCount;
	Console.WriteLine(t2 - t1);
    }

    private static byte[] RandomBytes()
    {
	//
	// Simple method to return a somewhat random string
	//
	StringBuilder builder = new StringBuilder();
	while (builder.Length < 20000)
	{
	    builder.Append(Path.GetRandomFileName());
	}
	return new ASCIIEncoding().GetBytes(builder.ToString());
    }
}

Enable GZIP

If you are working for a large organization, you will want to enable IIS7 compression on the server. However, many of us doing smaller-scale work won't have precise control over the server.

Internal ASP.NET compression. I learned on Rick Strahl's web log this interesting and useful technique for enabling compression directly in ASP.NET on your ASPX pages or code-behind files. You can use Response.Filter and GZipStream for ASP.NET compression.

Example code. Rick has more elaborate examples, but for my purposes I found using these two lines adequate. As I say, more lines of code means more possible bugs, so using these two lines in OnLoad or Page_Load in your ASP.NET pages is worth consideration.

Page that uses Response.Filter [C#]

using System;
using System.Web.UI;
using System.IO.Compression;

public partial class _Default : Page
{
    protected override void OnLoad(EventArgs e)
    {
	//
	// Apply GZIP compression (or DEFLATE)
	//
	Response.Filter = new GZipStream(Response.Filter,
	    CompressionMode.Compress);
	Response.AddHeader("Content-Encoding", "gzip");
    }
}

Results

The experiment shows that the time required for downloading a page, not including DNS connections, is larger than the time required for compressing that page. Note that the computer I tested the compression on is likely faster than the server, so the numbers may be closer.

When to compress. On many mostly-static sites that have minimal dynamic features, I like to combine output caching and compression. This reduces the CPU load of compressing but also reduces bandwidth. For a dynamic site with large pages, the cost of compression could go up ten times.

Larger pages. A site with 200 KB pages might take ten times more time to compress, around 20 ms. However, the server also requires CPU to send files and maintain connections. My intuition is that the benefits of compression would be much smaller for these sites.

Summary

We looked at some issues relating to HTTP compression in the ASP.NET web framework. Resources from the ASP.NET community helped this analysis. Online tools such as AOL Pagetest can give a valuable benchmark to your efforts. Use the GZipStream and Response.Filter code here to compress mostly static sites for a substantial performance win.