Static Content not cached properly in Dynamics CRM due to Vary:* header

Recently I have worked on a few different performance cases where the customer was either seeing slow form load performance or noticed high bandwidth usage. To see what was happening I gathered a fiddler trace and looked at the traffic. When gathering a fiddler trace I always open the form twice in a row to make sure static content has a chance to get cached. On any subsequent page loads we should only see dynamic pages being loaded. This would include aspx, asmx, ashx, and svc type of requests. However in this scenario I would see large JavaScript files being loaded each time I open the form.

I have a couple screenshots below showing the common offenders. These static files can account for nearly 1MB of extra data being downloaded with each form load. On a slower network connection it can add several seconds to the page load. 

These static files all have caching set to public however the Vary header in the response was being set to “*”. Anytime the Vary header is set to * it will prevent the client from caching the file.  The Vary header should be set to “Accept-Encoding”.  I have found a couple different culprits that cause this issue.

Issue 1: IIS is setting the Vary header to “*”.

In some cases IIS can set the Vary header to “*” instead of “Accept-Encoding”. I have primarily noticed this behavior on Windows Server 2012.  This can be easily prevented by changing the omitVaryStar IIS setting to True.   There are quite a few articles that can provide more detail on the omitVaryStar  setting, but this is something to look at if you are seeing the behavior.

Below are steps on how to change this setting

1. Select CRM site, and go to Configuration Editor.

2. Select system.web/caching/outputCache as Section, set True for omitVaryStar, click Apply to save the change.

This results in the Vary header in the response going back to “Accept-Encoding” and the browser is able to cache the static content properly.

Issue 2: Caching Features on Network Appliances adding Vary:* header.

There have been some scenarios where I’ve found that the Vary header was being impacted by network appliances.  In those cases the network appliances had their own caching or compression functionality which caused the Vary * header to be added. I’ve seen this behavior caused by Load Balancers, Firewalls, and Proxy Servers. These can be a little harder to track down, but in some cases you can access a server directly using IP or server name to see if the issue is still occurring. Once the source was identified the customer would either update the appliance configuration or disable the appliance caching functionality because it did not add noticeable benefit over what IIS was doing.

There may be other things that cause this behavior, but these are the two common things that I run into.  Feel free to drop a comment if you have seen other root causes to the behavior.

Thanks,

Jeremy Morlock

Microsoft Premier Field Engineer