This post is regarding compression your http result while not using IIS Dynamic Compression. And this is code to compress ASP.NET MVC 6 Response Manually:

using System;
using System.IO.Compression;
using System.Web;
namespace WebCompressionSample
{
    public static class ResponseCompressor
    {
        public static void Compress(HttpContext context)
        {
           {
               return;
            }
            string acceptEncoding = context.Request.Headers["Accept-Encoding"];
            if (string.IsNullOrEmpty(acceptEncoding))
            {
                return;
            }
            if (acceptEncoding.IndexOf("gzip",
                StringComparison.OrdinalIgnoreCase) > -1)
            {
                       context.Response.Filter = new GZipStream(
                       context.Response.Filter, CompressionMode.Compress);
                       context.Response.AppendHeader("Content-Encoding", "gzip");

            }
            else if (acceptEncoding.IndexOf("deflate",
                StringComparison.OrdinalIgnoreCase) > -1)
            {
                    context.Response.Filter = new DeflateStream(
                    context.Response.Filter, CompressionMode.Compress);
                   context.Response.AppendHeader("Content-Encoding", "deflate");
            }
        }
    }
}
Well, this shows a way to do the compression itself. Looking on however you are doing ASP.NET MVC, you most likely can call it otherwise.In my case, I referred to as it manually from an ASP.NET Webforms PageMethod (more on why below), however if you're using ASP.NET MVC for instance, you most likely wish to wrap it in an ActionFilter and apply that to the action you wish to compress its output. Let me apprehend within the comments or on twitter if you've got a problem implementing it in a particular situation.

IIS 7+ has built in dynamic compression support (compressing output of server-side scripts like ASP.NET, PHP, etc.). It’s not by default as a result of compression dynamic content means that running the compression for each request (because it doesn’t know what the server-side script can generate for each request, the purpose of using server-side programming is generating dynamic content).

Static compression on the opposite side (caching static files like styles and scripts) is on by default as a result of once the static resource is compressed, the compressed version is cached and served for each future request of an equivalent file (unless the file changes of course). I’d say if your server side scripts expect to come large text-based content (say, large data, even when paging, etc. like large reports or whatever), always turn dynamic compression on, a minimum of for the pages that expect to come massive data sets of text.

In several cases though the majority of huge files will be scripts (and probably images) will be the larger components though, which are usually taken care of (for scripts for example) by IIS static compression or ASP.NET Bundling.