Why is gzip compression not working on IIS 8.5?

Question

I am unable to get gzip compression working on IIS 8.5 on a Server 2012 R2 machine. I have done some research and followed the instructions found in these posts:

1. How to enable GZIP compression in IIS 7.5
2. Compression in IIS 8.5 not successful, stating ALREADY_CONTENT_ENCODING
3. GZip Compression On IIS 7.5 is not working
4. gzip compression not working with IIS 8.5

Here is the relevant section of my config:

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" staticCompressionIgnoreHitFrequency="true">
    <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
    <!-- I have read that dynamic compression increases server CPU load.
    <dynamicTypes>
        <add mimeType="text/*" enabled="true"/>
        <add mimeType="message/*" enabled="true"/>
        <add mimeType="application/javascript" enabled="true"/>
        <add mimeType="*/*" enabled="false"/>
    </dynamicTypes>
    -->
    <staticTypes>
        <add mimeType="text/*" enabled="true" />
        <add mimeType="message/*" enabled="true" />
        <add mimeType="application/javascript" enabled="true" />
        <add mimeType="*/*" enabled="false" />
    </staticTypes>
</httpCompression>
<urlCompression doStaticCompression="true" doDynamicCompression="true" />

Also, in IIS, I set compression to apply to anything larger than 256 bytes. And I have performed iisreset.

Nonetheless, I don't see the compression mentioned in my dev console in Chrome or IE and PageSpeed still tells me to compress stuff. What simple step have I missed?

Mastery

Answer 1

It will be difficult to understand what is happening.Assuming that you have done all the IIS settings correct.

• For checking if compression is working fine or not,How are you accessing the website. e.g. If you use an FQDN www.example.com ,please try and use localhost url. This will make sure your IIS settings are correct.
• If localhost works fine and your Fully Qualified domain name does not work,then problem can be in the network.In order for compression to work,the browser needs to send request header accept-encoding:gzip, deflate . many at times your proxy or load balancer can trim this header and this header may not reach the IIS server.So IIS will never compresseven if all the settings are done right.

To verify what is happening for the request and why IIS did not compress the request,you can do the following.

• make sure you have Failed Request tracing installed.
• Configure your Failed Request Definition
  • Go to Failed Request tracing Modules
  • Click Add on the sidebar
  • Enable All Content and status as 200-999
  • And Finish the configuration.
  • Now reproduce the issue and you will get a traces captured in directory C:\inetpub\logs\FailedReqLogFiles\W3SVC .
  • Open the trace file(for each requests one file will be generated.Open the trace file in IE(make sure the request details matches the request you would like to verify) and go to the compact view
  • Search for Compression and also check the reason

Afterpiece

I tried this out, found one of files that should be getting compressed, and I see the STATIC_COMPRESSION_NOT_SUCCESS detail is "Reason="NOT_FREQUENTLY_HIT"". Should this have been avoided because I set staticCompressionIgnoreHitFrequency in my config? – Mastery

frequentHitThreshold is a limit which applies to the static compression rule.yes you can set staticCompressionIgnoreHitFrequency to always compress – Afterpiece

Right. I had already done that, yet I see it is not compressing. Is there something that could override that? – Mastery

Try setting the frequentHitThreshold to zero and verify. staticCompressionIgnoreHitFrequency should handle the compression.Also compressin has a min file size .So the file you are testing should be above the min file size.After all this verified,what is coming in the Failred request tracing compression Reason – Afterpiece

Answer 2

As mentioned in answers to one of the questions the OP links to, be sure to check for any anti-virus software running on the server. In my case it was ESET. None of the IIS compression settings had an effect until the relevant ESET settings were disabled.

I'm leaving out details of the settings- I did what seemed like a pretty blanket disable and left it to IT to figure out which exact setting was most appropriate for compression to still work while retaining security.

Fenderson

Answer 3

I had a similar issue and was caused by ESET with some strange behavior. It worked on some machines but not on the one with eset, it took me some time to realize.

What happened is that ESET caused chrome to downgrade http2 requests to http 1.1 and not compress them. It can be seen if you open network and enable 'protocol' column. After removing eset it worked even if I forced chrome to use http1.1 with '--disable-http2' flag

Anyway if it still not working I would try to (in addition to the other answers):

• check if different clients behave the same (in my case only dev machine had the issue)
• deploy a simple static site (event default one) and test
• reinstall iis
• check settings on iss server manager, configuration editor / system.webServer/httpCompression collection, change compression level

Burd

Answer 4

I was facing the same issue and found that WWW service must be restarted to have changes for compression level applicable https://learn.microsoft.com/en-us/iis/configuration/system.webServer/httpCompression/scheme

Lues