We have just managed to get GZIP working in IIS by adding the type
application/grpc-web
Inside of the httpCompression part of IIS. This correctly sets the Content-Encoding to gzip and we see a smaller footprint of the byte transfer. However, in ASP.NET we saw that one could also gzip the content of the data like this:
options.ResponseCompressionLevel = System.IO.Compression.CompressionLevel.Optimal;
options.ResponseCompressionAlgorithm = "gzip";
Which way is the most efficient in terms of data size? Or would it be equivalent to setting the gzip as above? One benefit of using the IIS gzip is that one can see the content clearly in developer console. If using the ASP.NET gzip the content is compressed also in the developer console.
As far as I know, you may need to analyze their pros and cons and make your own choice based on your requirement.
ASP.NET gzip: better flexibility (such as using different compression methods for different scenarios). But this will definitely increase the code complexity of the application and affect its overall performance.
IIS gzip: Using a dedicated thread pool generally results in better performance because it makes better use of server resources and reduces the amount of redundant configuration work. But it lacks the flexibility as mentioned above.
Therefore, the compression performance of IIS configuration will usually be better, I recommend you implement this via IIS configuration. But based on the complexity of your application, or if need some special requirements, configuration through code is also a valid option, which will be up to you.