Response Compression in ASP.NET Core

What is response compression?

Response compression is a technique that can be used to reduce the size of HTTP responses.

Response compression reduces the size of the HTTP response, which ultimately increases the responsiveness of the app.

Benefits of response compression

Pros of response compression are listed below.

1. Improved performance: Compressing the response can reduce the amount of data that needs to be transmitted over the network, leading to faster page load times and a better user experience.
2. Reduced bandwidth usage: By compressing the response, you can reduce the amount of data that is transmitted over the network, which can lead to reduced bandwidth usage and lower costs for hosting and bandwidth
3. Better SEO: Search engines consider page load times when ranking websites so that a faster-loading website may rank higher in search results.

How to implement response compression?

We can configure it using the. NET middleware —> AddResponseCompression like this.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
});

var app = builder.Build();
app.UseResponseCompression();
app.MapGet("/", () => "Hello World!");
app.Run();

When we set EnableForHttps = true, it can expose our requests to CRIME and BREACH attacks, so while using response compression, make sure to avoid them by using anti-forgery tokens when you are compressing data.

Compression Providers

.NET provides us with two compression providers.

• Brotli Compression
• gzip compression

By default, .NET middleware uses the Brotli Compression Provider.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options. Providers.Add<BrotliCompressProvider>(); 
    options. Providers.Add<GzipCompressProvider>();
    options.MimeTypes = ResponseCompressionDefaults.MimeTypes;
});

Compression Levels

Each provider has the following compression levels.

1. Optimal: The compression operation should be optimally compressed, even if the operation takes a longer time to complete
2. Fastest: The compression operation should complete as quickly as possible, even if the resulting file is not optimally compressed
3. No Compression: No compression should be performed on the file
4. Smallest Size: The compression operation should create output as small as possible, even if the operation takes a longer time to complete

This is how we can set compression levels for our providers.

builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.SmallestSize;
});
builder.Services.Configure<GzipCompressProviderOptions>(options =>
{
    options.Level = CompressionLevel.Optimal;
};

Custom providers

Create a simple class and implement the ICompressionProvider method, and then you can add your CustomCompressionProvider like this in the Program file.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression(options =>
{
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
    options.Providers.Add<CustomCompressionProvider>();
});

var app = builder.Build();

app.UseResponseCompression();
app.Run();

When should we compress and when not?

1. Responses that are not natively compressed(e.g. CSS, JS, HTML, XML, JSON) are the best candidates for compression.
2. Don’t compress natively compressed assets (e.g. PNG) and smaller files (with 150-1000 bytes)

How can I verify that my compression is working?

Add middlewares, set compression levels, and send requests from Postman by setting different values of Accept-Encoding in the header.

MIME Types Supported by Default

These are the MIME types by default supported.

• text/css
• text/xml
• text/json
• text/html
• text/plain
• application/xml
• application/json
• application/wasm
• application/javascript