In my last post, I covered improving web application performance by caching static resources. Another effective improvement is response compression. Most browsers support deflate, gzip, and more recently brotli.
If you host your ASP.NET Core application on IIS or nginx, you may already benefit from built-in compression. However, if you are not using a reverse proxy that handles compression, or prefer not to rely on one, ASP.NET Core provides a response compression middleware.
Install the NuGet package Microsoft.AspNetCore.ResponseCompression (NuGet, GitHub)
Edit the ConfigureServices method in Startup.cs:
C#
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<GzipCompressionProviderOptions>(options => options.Level = System.IO.Compression.CompressionLevel.Fastest);
services.AddResponseCompression();
}
Add the middleware in the pipeline
C#
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
// Must be before UseStaticFiles to compress static files and UseMvc to compress MVC responses
app.UseResponseCompression();
app.UseStaticFiles();
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}
Let's have a look using Chrome

With response compression enabled, the page size drops by about 50% (580 kB to 205 kB). That said, looking at the screenshot, you can see that some compressible resources, such as SVG files, are still not compressed.
#Compressing more files
The middleware determines which resources to compress based on their MIME types. By default, only plain text, HTML, CSS, JavaScript, and JSON files are compressed. You can find the full list on GitHub.
To include SVG files, update the middleware configuration:
C#
public void ConfigureServices(IServiceCollection services)
{
services.Configure<GzipCompressionProviderOptions>(options => options.Level = System.IO.Compression.CompressionLevel.Optimal);
services.AddResponseCompression(options =>
{
options.MimeTypes = new[]
{
// Default
"text/plain",
"text/css",
"application/javascript",
"text/html",
"application/xml",
"text/xml",
"application/json",
"text/json",
// Custom
"image/svg+xml"
};
});
}

The middleware is about 28% slower than IIS compression (source). Additionally, IIS and nginx apply a minimum size threshold to avoid compressing very small files. This setting is not yet available in the middleware, but may be added in the future (GitHub issue).
#Security
Security is an important consideration. Known attacks such as BREACH exploit HTTP-layer compression to allow an attacker to infer secrets. A site is vulnerable to BREACH if (source):
- Your page is served with HTTP compression enabled (GZIP / DEFLATE)
- Your page reflects user data via query string parameters, POST…
- Your application page serves PII (Personally identifiable information), a CSRF token, sensitive data…
In this case, you should disable compression or apply appropriate mitigations. If you understand the risks, you can explicitly enable compression for HTTPS requests:
C#
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.Configure<GzipCompressionProviderOptions>(options => options.Level = System.IO.Compression.CompressionLevel.Fastest);
services.AddResponseCompression(options =>
{
options.EnableForHttps = true;
});
}
#Conclusion
Compression is a simple and effective way to reduce page size and improve loading times. The response compression middleware is straightforward to configure. Use Fiddler or your browser's developer console to verify that all compressible resources are being compressed. For the best performance, prefer the compression provided by IIS or nginx. You can also extend the middleware with additional algorithms such as Brotli. See a great example in this blog post.
Do you have a question or a suggestion about this post? Contact me!