Compression Before Cache
Sitefinity recommend setting Dynamic Compression Before Cache to true. So why then do they set it as false by default?
After the Sitefinity 8.2 release I was looking through the recommendations in the documentation and I saw a one to enable Dynamic Compression Before Cache. Thing was, I was setting this to false and it took me a moment, (and testing), to recall why.
ASP.NET Cache Substitution
The primary reason you should set this field to false is when you are using ASP.NET's cache substitution. I wrote a post on doing that previously. Thing is, if you do use it and set dynamic compression to true then your page will exploded when the substitution runs with an error:
Post cache substitution is not compatible with modules in the IIS integrated pipeline that modify the response buffers.
So the if you are not using that functionality then go ahead and enable the Dynamic Compression Before Cache setting to true. But....
Why does Sitefinity set this to false by default?
Turns out, some of their controls use cache substitution. Namely the Logged In User widget. To be honest I think this is the only control that does. I did a search and only found this control. So if you do enable this setting you can't use that widget. (The Web Forms widget that is. The new Feather widget is fine.) For me, I just created a web service which does the same thing. So the page can still be cached and on-load it makes a call to get the name of the logged in user and displays the user name or a log in link. And, in all honesty, this is what I recommend you should always look at doing this as the default solution. The substitution option works but I think that it should not be a first pick option as it is a little cumbersome. It stinks that you can only deal with string output as one example. At least in my opinion.
Thanks for reading and feel free to comment - Darrin Robertson
Make a Comment