Response Compression in .NET World

What’s this thing?

This middleware is responsible for compressing the response payload to reduce the size of the response.

But why?

Speed and money rule the world.
If you get a smaller response, you get an improved performance.
The second one is about money. How can this thing help you gain or not lose, so much money? Well, it’s simple: network bandwidth has a cost. Forget about your gigabyte bandwidth, and think about locations in which you use GSM Data which is working very slow (so not 4–5G) and costs a lot! Think about those customers! If your app does not have such clients, probably the benefits turn into benefits, so, only speed for you.

Speed is not enough for you? Believe me, it should be! I know a lot of people who if they don’t find what they are looking for in 5 sec, go on the next URL from Google. And that 5 sec includes the page load, so you really want the best user experience, page load time and so on, that you can get.

Better SEO. Search engines love fast websites, so yours will most likely get pushed upper in their ranks.

I’m lazy. Built-in providers?

Yes. Microsoft provides 2 provider types: BrotliCompressionProvider and GzipCompressionProvider, basically for text and images, but I don’t see the reason for me to re-iterate what is already been written on the documentation page so everything you know plus examples can be found here. Examples in .NET 8 of course. If you want to build your custom compression provider, I found an old example here.

Level of compression

• Fastest — Should return as fast as possible even if the result file is not optimally compressed
• NoCompression — Do nothing
• Optimal — It should do a balance between speed (the time it takes to do the compression) and the output size
• SmallestSize — It should return the smallest size, even if the compression will take a little bit longer.

Supported Mime Types

Supported mime types directly from Microsoft code, can be found here

Note:
Wildcards like text/* aren’t supported!

Personal Experience

I last made real tests (with hundreds of thousands of calls) in the days when .NET6 was “the king”. In those days, I didn’t see much difference between Fastest and Optimal in terms of speed, so in my projects, I usually used Fastest or SmallestSize depending on what was more important to me. If no one else besides me cared about compression I’d use Fastest, if size matters I’d use SmallestSize.