Azure Web App Not Using GZip Compression

Question

I was using WebPageTest to test the performance of my Azure Web App (ASP.Net vNext Web API/Angular). I got an F for both \"Compress Transfer\" and \"Cache Static Content\".<

Answer 1

Just to back up @theadriangreen here - it will be a header problem. I've found adding the types in the web.config to be unreliable.

What you need to do instead is edit the applicationHost.config file stored in the deepest dark part of azure. The easiest way to do this, is to install the IIS Manager extension either in the Azure portal or in Kudu. Kudu can be accessed via .scm.azurewebsites.net.

There you can edit the file, and it'll save a xdt for you - which once you restart the app you should find that the xdt gets applied.

Alternatively, you can just add an applicationHost.xdt to your App root and you are good to go. Here is a sample.

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <httpCompression>
      <dynamicTypes>
        <add mimeType="application/json;charset=utf-8" enabled="true" xdt:Transform="InsertAfter(/configuration/system.webServer/httpCompression/dynamicTypes/add[(@mimeType='application/json')])" />
      </dynamicTypes>
    </httpCompression>
  </system.webServer>
</configuration>

References:-

• https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples
• https://blogs.msdn.microsoft.com/benjaminperkins/2015/03/03/making-changes-to-the-applicationhost-config-on-azure-websites/
• https://github.com/shibayan/IISManager

Answer 2

gzip compression is enabled by default for Azure Web Apps. You can see the rules in your sites LocalSiteRoot/Config/applicationhost.config. Looking at the response headers (which can easily be done with developer tools) should confirm that gzip is being used. It is possible that one of the resources that your site loads is not compressed, and this is causing the WebPageTest to fail. I would look at a network capture and the response headers, and see if you can find the offending resources if you're concerned.

To go to the local site root, you can use FTP, or go to your SCM site at https://.scm.azurewebsites.net/DebugConsole and then click the globe icon.

Also I suspect that your 2 javascript files are not getting compressed since the Content-Type header is not getting populated, so the rule is not capturing it because it does not recognize the mimetype.