ASP.NET Core Response Compression with Brotli & Gzip

Serving a 1 MB JSON payload over slow mobile networks? You’re leaving users waiting and cloud bills higher than needed. The good news: ASP.NET Core’s built-in response compression can cut your payload sizes by 60-80% with just a few lines of middleware configuration. Let’s enable Brotli and Gzip compression in minutes without breaking existing functionality.

What you’ll learn:

• Enable compression middleware with production-ready configuration
• Avoid common gotchas with static files and reverse proxies
• Verify compression works and secure your setup properly

Tested on .NET 8.0 in Azure App Service environments.

Why Response Compression Actually Matters

Modern web applications push substantial data over the wire. Whether you’re serving API responses, static assets, or dynamic content, uncompressed payloads create three immediate problems: higher bandwidth costs, slower time to first byte (TTFB), and poor user experience. Response compression middleware automatically negotiates with browsers using Accept-Encoding headers. No client-side changes required.

Enable Compression in Two Steps

ASP.NET Core includes production-ready compression providers out of the box. Here’s the minimal setup in your Program.cs:

var builder = WebApplication.CreateBuilder(args);

// Configure compression services
builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add<BrotliCompressionProvider>();
    options.Providers.Add<GzipCompressionProvider>();
});

// Optimize Brotli for speed over size
builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
    options.Level = CompressionLevel.Fastest;
});

var app = builder.Build();

// Add middleware to pipeline
app.UseResponseCompression();
app.MapControllers();

app.Run();

Key configuration details:

• EnableForHttps = true allows compression over HTTPS connections (disabled by default for security)
• Provider order matters: Brotli first, then Gzip fallback for older browsers
• CompressionLevel.Fastest prioritizes CPU performance over maximum compression ratio

Expert Tip: I’ve found CompressionLevel.Fastest provides the best balance for high-traffic applications. The size difference compared to Optimal is typically under 5%, but CPU usage drops significantly.

Production Tweaks and Common Gotchas

Static File Handling

If serving static files, middleware order becomes critical:

app.UseStaticFiles(); // Must come before UseResponseCompression
app.UseResponseCompression();

Static files bypass compression middleware if added afterward, leaving CSS, JS, and images uncompressed.

Content Type Configuration

By default, ASP.NET Core compresses common text-based content types. For custom content types, explicitly configure them:

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat(new[]
    {
        "application/json",
        "application/api+json",
        "text/csv"
    });
});

Reverse Proxy Considerations

Compression works seamlessly with reverse proxies like Nginx, CloudFront, or Azure Application Gateway. The middleware automatically detects when content is already compressed and skips redundant processing.

Real-World Performance Impact

Compression typically achieves 70-80% size reduction for JSON responses and HTML content in production applications serving millions of requests monthly. CSS and JavaScript bundles often compress even better due to repetitive patterns and whitespace.

Verify and Secure Your Setup

Verify compression works by checking browser developer tools Network tab for the Content-Encoding header:

Content-Encoding: br
Content-Length: 28453

Missing this header means compression isn’t active for that response.

Avoid double compression. If your reverse proxy or CDN already compresses responses, disable middleware compression to prevent CPU waste:

// In production behind CloudFront
if (!app.Environment.IsDevelopment())
{
    // Skip compression, handled by CDN
}
else
{
    app.UseResponseCompression();
}

Personal Experience: I once debugged a mysterious CPU spike that turned out to be double compression. Always check your infrastructure stack before enabling middleware compression in production.

Advanced Scenarios

Conditional Compression

For applications serving mixed content sizes, consider implementing size-based logic in a custom compression provider. Small payloads under 1KB often don’t benefit from compression overhead:

public class ConditionalCompressionProvider : ICompressionProvider
{
    public string EncodingName => "conditional";
    public bool SupportsFlush => true;
    
    public Stream CreateStream(Stream outputStream)
    {
        var context = // Get current HttpContext
        
        if (ShouldCompress(context))
        {
            return new BrotliStream(outputStream, CompressionLevel.Fastest);
        }
        
        return outputStream; // Skip compression
    }
    
    private bool ShouldCompress(HttpContext context)
    {
        // Custom logic based on route, content length, etc.
        return context.Response.ContentLength > 1024;
    }
}

Instant Bandwidth Savings

Response compression middleware delivers immediate performance gains with minimal configuration overhead. Two lines of middleware setup can reduce your bandwidth costs by 60-80% while improving user experience across all device types.

Consider pairing compression with output caching strategies for maximum performance impact. When compression and caching work together, you serve pre-compressed, cached responses that hit your servers less frequently and transfer faster when they do.

References

• Microsoft Docs: Response Compression Middleware
• Brotli RFC 7932 Specification
• ASP.NET Core Performance Best Practices
• HTTP Compression Security Considerations

Frequently Asked Questions

Related Posts

• Correct Middleware Order in ASP.NET Core Apps
• Hybrid Caching Strategies Beyond MemoryCache in ASP.NET Core
• EF Core Interceptors for Secure, Per-Tenant Audit Logging
• 5 ASP.NET Core DI Scope Mistakes Developers Must Avoid
• SaaS Middleware Anti-Patterns: What Not to Do in ASP.NET Core