IIS - Http Compression IIS6.0

Asked By TechMate

28-Feb-07 10:38 AM

With IIS 6.0 Compression enabled, can I use that for compressing .js
and/or .css files?? I tried to add "js" to the HCFileExtensions and
HCScriptFileExtensions in the Metabase file (separately and together),
but I see the entries are removed after doing an IISReset... has
anyone compressed javascript or Css files?? Is it even possible
without third-party plugins??

28-Feb-07 01:00 PM

Sure, you can use IIS6 Static and Dynamic Compression for arbitrary
resource extensions. No need for third party plugins at all.

If you see metabase entries removed after doing an IISReset, then you
did not add the entry properly. Specifically, you cannot edit the
metabase file unless you have "edit while running" enabled, and if you
make changes to the in-memory representation and the process is killed
by IISReset before flushing to disk, it also causes loss of change.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

01-Mar-07 09:51 AM

Is it possible to verify that the http requests are getting compressed
JS files after proper configuration? There are some web speed report
sites that can give a detailed report on the bytes transferred for
requests.

I tried one such site websiteoptimization.com and I can see the
compressed content for HTML but not on JS script files. Does this mean
that the script files are not compressed by the requests? I do see IIS
able to compress the script files in "IIS Compressed Files" folder on
the server. I am a little confused as to whether adding .js to static
compression is useful or not.

01-Mar-07 10:43 PM

I really do not know if those websites are making the correct requests
to verify functionality, so I cannot comment on what you observe with
them.

I can only say that after proper configuration, make an HTTP request
for the .js resource with header "Accept-Encoding: gzip".

The response to the first request will be uncompressed. On subsequent
responses, it will be compressed with added "Content-Encoding: gzip"
header.

Web Browsers will do the above, so my test is directly comparable to
what will happen in reality.

As to whether adding .js to static compression is useful or not --
completely depends on what you want.

By default, .js is considered static file and subject to static
compression of 40-60% reduction in average bandwidth for plain text
files. It is possible to configure (intentionally or unintentionally)
for .js to be considered "dynamic" by IIS (even though it's still just
a file) and subject to dynamic compression instead.

Thus, if you are looking at "how well does .js compress", it comes
down to:
1. Did you configure the client to request compression for the
resource
2. Did you configure the server to allow compression (dynamic or
static) for the resource extension at that URL
3. Is the resource extension configured to be treated as dynamic/
static by IIS such that it is subject to dynamic/static compression

If you don't do everything correctly, you simply cannot believe the
results you observe because it will be incomplete.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

02-Mar-07 11:42 AM

Another question, if all configurations are set right and we decide to
go with STATIC compression, what happens when the actual JS file is
modified or updated. Does IIS recognize the change and re-create the
compressed cache file or do we have to clear the cache files first??

03-Mar-07 03:13 AM

IIS will do the optimal behavior - recognize the modified file and
dynamically evict the cached response - because Windows offers
FileChangeNotification.

This is unlike Apache and *nix which does not have
FileChangeNotification and thus must restart to have any such change
take effect.

Same goes for .htaccess -- it is a performance drain for Apache that
defaults to disabled, but distributed web.config on IIS7 (.htaccess,
but better) scales perfectly because of FileChangeNotification and is
enabled by default.



//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//