4

I made some changes to the web.config of a server running IIS 7.5 improve the performance (mostly front-end).

A 3rd party testing tool says the site is running "PHP/5.3.10, ASP.NET" and if memory serves, it is ASP.NET 4.5

I think it's due to the odd mix of technologies (e.g. running PHP on IIS) but touching anything makes me nervous.

I added (only) the directives for expires headers and gzip from the H5BP IIS server config

I think I added those directives on the afternoon of Jan. 15th 2013. The test history of the site from the Pingdom performance testing tool is available here.

You can see where the transfer size sharply drops off (click on the history tab).

Since then it seems like every time I test it, different files (generally assets like CSS & JS) are or aren't served with gzip with no rhyme or reason. Sometimes everything seems to be served with gzip, sometimes almost nothing seems to be served compressed but it's usually somewhere in the middle (as you can see in the history).

What is going on?

How can I fix it?

This site is not under active development, while some extra data has been added to the page (Google Analytics plugin scripts I added to improve tracking) after the 15th, there is nothing that should explain such large variations and inconsistencies.

My best guess is that it is related to CPU resources for compression, and this question seems close: Why is gzip compression varying in efficiency in IIS?

adam-asdf
  • 191
  • 1
  • 11
  • I have just observed the same behaviour. Sometimes static assets are gzipped, sometimes they are not. I am pretty sure it's related to server CPU as you have indicated above. – agrath Mar 26 '14 at 02:49

1 Answers1

7

I found a likely culprit in the comments of this page; weblog.west-wind.com

Essentially, OOTB, IIS will only gzip if the file is requested at least twice in 10 seconds.

This is tuned via in web.config - unfortunately that's locked by default so you have to edit applicationhost.config to change the overrideModeDefault="DENY" to ALLOW.

Reference for that is here: forums.iis.net

Relevant config snippets are as follows. You will see I am also messing with the content type for SVG fonts as by default IIS will not gzip them, so by forcing them to text/xml they get compressed too. (Google PageSpeed complains about this)

web.config

  <system.webServer>
        <serverRuntime frequentHitThreshold="1" enabled="true" />
        <staticContent>
              <clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="30.00:00:00" />
              <remove fileExtension=".svg" />
              <mimeMap fileExtension=".svg" mimeType="text/xml" />
        </staticContent>
        <httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
            <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
            <dynamicTypes>
                <add mimeType="*/*" enabled="true" />
            </dynamicTypes>
            <staticTypes>
                <add mimeType="image/svg+xml" enabled="true" />
                <add mimeType="text/xml" enabled="true" />
                <add mimeType="*/*" enabled="true" />
            </staticTypes>
        </httpCompression>
        <urlCompression doStaticCompression="true" doDynamicCompression="true"/>
    </system.webServer>

applicationHost.config

      <section name="serverRuntime" overrideModeDefault="Allow" />
agrath
  • 261
  • 2
  • 10
  • Works like a charm ! Your sir are a genius! – Hugo Hilário Nov 18 '15 at 12:09
  • I'm seeing really weird results still even after these changes. On one machine the SVG files are never Gzipped no matter what browser I try and on another they are always Gzipped. – ProNotion Nov 01 '17 at 11:31
  • @ProNotion confirm the mime type is text/xml for the .svg files on both machines. – agrath Nov 04 '17 at 03:13
  • On the client machines? – ProNotion Nov 05 '17 at 16:03
  • @ProNotion sorry, i thought you meant two different servers were behaving differently. Still worth checking though? – agrath Nov 05 '17 at 19:24
  • No, the server and site is serving different results to different machines or for some reason one of the client machines is just not accepting the gzipped response despite the request saying it supports it. Also, for reference we are serving them as `image/svg+xml` not `text/xml\ – ProNotion Nov 05 '17 at 21:33
  • When I set ``, SVG are not being rendered in the browser (tested on Chrome, Firefox and Edge). When I set `mimeType` back to `image/svg+xml`, SVGs are rendered again. – zed Feb 27 '18 at 20:56
  • @zed sounds like a change since this original post, good tip – agrath Feb 27 '18 at 21:17