MNW #044: Response Compression in ASP.NET Core

MNW #044: Response Compression In ASP.NET Core

Read time: 4 minutes

A big thank you to our sponsors who keep this newsletter free to the reader:

Today's issue is sponsored by IcePanel. IcePanel realigns your engineering & product teammates on the technical decisions made across the business. Explain your complex software systems with an interactive map that teammates can drill down to the level of detail they need.

And by Treblle. Treblle is a lightweight SDK that helps engineering and product teams build, ship & maintain REST-based APIs faster. Simple integration for all popular languages & frameworks, including an SDK for .NET 6.

Reducing the size of your API responses can noticeably improve the performance of your application.

And since network bandwidth is a limited resource, you should at least consider the benefits of response compression.

Here's what you'll learn in this week's newsletter:

How to configure response compression in .NET
Server-based vs. application-based compression
Possible security risks and mitigation strategies
How to configure the available compression providers
How much network bandwidth you could be saving

Let's get started.

Configuring Response Compression

Using response compression in an .NET applications is remarkably easy.

You only have to call these two methods:

AddResponseCompression - to configure the default services for response compression
UseResponseCompression - to add the response compression middleware to the request pipeline

The UseResponseCompression method should be called before any middleware that compresses responses.

Response compression isn't turned on by default for HTTPS, so you have to enable it by setting EnableForHttps to true.

It really is that simple.

But...

When Should You Use Response Compression?

Ideally, you want to be using server-based response compression if your application server supports it.

Because the middleware performs response compression at the application level, it will typically have worse performance.

If you are hosting your application and you can't use server-based compression, then using the response compression middleware is justified.

One more concern should be security, because using response compression over HTTPS can expose you to CRIME and BREACH attacks

Here's what you can do to improve security:

You can mitigate CRIME and BREACH attacks by introducing anti-forgery tokens in ASP.NET Core
Don't send application secrets as part of the request body
Implement a rate limiter

Configuring Compression Providers

There are two compression providers added by default when you call AddResponseCompression:

BrotliCompressionProvider
GzipCompressionProvider

You can further customize the available providers by adding custom compression providers if you want to.

Compression will default to Brotli compression when it's supported by the client. Otherwise, it will default to Gzip if that is the supported compression format.

The interesting thing is you can configure the CompressionLevel for the Brotli and Gzip compression providers.

There are four possible values:

Optimal - tries to balance response size and compression speed
Fastest - sacrifices optimal compression for improved speed
NoCompression - self explanatory
SmallestSize - sacrifices compression speed to make the output as small as possible

The default value is CompressionLevel.Fastest.

How Much Can You Save?

Let's find out how much network bandwidth we can save by using response compression.

Here's a minimal API endpoint returning a list of Message objects:

And here are the results with different providers and compression levels:

No compression - 4500B (4.5kB)
Gzip + CompressionLevel.Fastest - 569B
Gzip + CompressionLevel.SmallestSize - 539B
Gzip + CompressionLevel.Optimal - 554B
Brotli + CompressionLevel.Fastest - 400B
Brotli + CompressionLevel.SmallestSize - 296B
Brotli + CompressionLevel.Optimal - 319B

Brotli is the clear winner, which is why it's the default compression provider.

In the best case scenario, you can reduce the response size by ~93.5%. Multiply this by the number of requests you're serving daily, and then you can begin to estimate the possible network savings.

One more thing I noticed is that using CompressionLevel.SmallestSize has a noticeable negative impact on response time. I can't say this was surprising, so I suggest to simply keep using the default compression level.

In Summary

Response compression is an interesting technique to improve API performance and reduce network costs.

Ideally, you'd want to be using server-based response compression if it's supported by your application server. If that's not the case, application-based compression is available in .NET with the response compression middleware.

What's the cost of response compression?

It will increase the CPU load, and can expose some security risks over HTTPS, but there are ways to mitigate this.

In my experience, the default configuration values for the compression provider and compression level give excellent results.

That's all for this week.

See you next Saturday.

Today's action step: To see the value of response compression, I suggest enabling it in your application and examining the changes in response size. You can try the different compression providers by varying the Accept-Encoding header, and also configure different compression levels in your application.

Whenever you're ready, there are 2 ways I can help you 🎁

If you're looking to join a community of like-minded engineers or you want to access all of the source code that I use in my YouTube videos, you can do that by becoming a Patron. Join 720+ engineers here.
Promote yourself to 23,000+ subscribers by sponsoring this newsletter (booked out 2 months)

You received this email because you subscribed to our list. You can unsubscribe at any time.

Dragise Cvetkovica 2, Niš, 18000, Serbia

Older messages

MNW #043: Adding Real-Time Functionality To .NET Applications With SignalR

Saturday, June 24, 2023

If you need real-time functionality in your app, look no further than SignalR ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ View In The Browser

MNW #042: Refactoring From an Anemic Domain Model To a Rich Domain Model

Tuesday, June 20, 2023

Find out if anemic domain model is an antipattern, and how a rich domain model can help ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ View In

MNW #041: The Right Way To Use HttpClient In .NET

Monday, June 12, 2023

Find out what are the best practice and guidelines for using HttpClient in .NET ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ View In The

MNW #040: Scheduling Background Jobs With Quartz.NET

Saturday, June 3, 2023

Find out how to easy it is to create and schedule background jobs with Quartz.NET ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ View In The

MNW #039: Build a CI/CD Pipeline With GitHub Actions And .NET

Saturday, May 27, 2023

Imagine being able to automatically build, test, and deploy your .NET applications with every code change ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌

JSK Daily for Sep 22, 2023

Friday, September 22, 2023

JSK Daily for Sep 22, 2023 View this email in your browser A community curated daily e-mail of JavaScript news Enhance Your Website with Scroll Animations Using Pure CSS, No JavaScript Required In this

Startups Weekly - Bay Area baby belly beholding Battlefield bounty

Friday, September 22, 2023

TechCrunch Newsletter TechCrunch logo Startups Weekly logo By Haje Jan Kamps Friday, September 22, 2023 Welcome to Startups Weekly. If this newsletter comes across as a deranged delirium of barely

iOS Dev Weekly - Issue 628

Friday, September 22, 2023

What does the future of testing in Swift look like? Find out, and give feedback! 📚 View on the Web Archives ISSUE 628 September 22nd 2023 Comment Happy new device day! Thanks also for all of the kind

Daily Coding Problem: Problem #1220 [Easy]

Friday, September 22, 2023

Daily Coding Problem Good morning! Here's your coding interview problem for today. This problem was asked by Salesforce. Write a program to merge two binary trees. Each node in the new tree should

Issue #507: JS Gamedev Summit, Jump Ship Jam, and deep space

Friday, September 22, 2023

Weekly newsletter about HTML5 Game Development. Is this email not displaying correctly? View it in your browser. Issue #507 - September 22nd 2023 If you have anything you want to share with the HTML5

Charted | The World’s Biggest Oil Producers 🛢️

Friday, September 22, 2023

Just three countries make up the lion's share of global oil supply. Here are the world's biggest oil producers. View Online | Subscribe Presented by: The best-informed investors choose

Questions every VC needs to ask about every AI startup's tech stack

Friday, September 22, 2023

TechCrunch+ Newsletter TechCrunch+ logo TechCrunch+ Roundup logo By Walter Thompson Friday, September 22, 2023 Welcome to TechCrunch+ Friday Image Credits: Rosemary Calvert / Getty Images Few VCs are

Studio Bot expands to 170+ international markets!

Friday, September 22, 2023

View in browser 🔖 Articles Studio Bot expands to 170+ international markets! Studio Bot can accelerate your ability to write high-quality Android apps faster by helping generate code for your app,

Noonification: LiteLLM Configs: Reliably Call 100+ LLMs

Friday, September 22, 2023

Top Tech Content sent at Noon! Join to Learn Whys and Hows of Storytelling for Startups How are you, @hacker? 🪐 What's happening in tech this week: The Noonification by HackerNoon has got you

Dot Leap Feedback

Friday, September 22, 2023

We interrupt your regularly scheduled program to build Dot Leap 2.0 ❤️ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌