Modern browsers have the ability to decompress files, so you can reduce the time needed to download files to the browser by sending them in a compressed format. Text files compress very well. For example, the MicrosoftAjax.js file is about 85KB originally, but when compressed, it is reduced to about 25KB. There is some extra CPU usage on the server to do the compression, but the compressed scripts can be cached on the server, so the processing overhead shouldn’t matter much. The client will decompress the file once and then cache it as well so the impact there is minimal and the overall effect can be a benefit to the server and to the client.
The compression of dynamic scripts is controlled in the web.config file. The enableCompression and enableCaching attributes should be set to true:
<system.web.extensions> <scripting> <scriptResourceHandler enableCompression="true" enableCaching="true" /> </scripting> </system.web.extensions>
Note that there are some tradeoffs in using compression and caching. Using compression without caching will make the server perform the compression work for every request. This can increase the load significantly on the server. However, caching the scripts can increase the memory used by the ASP.NET worker process, putting pressure on the cache and affecting the overall throughput as a result.
On the other hand, the compressed scripts are smaller and thus transmitted more quickly to the browser, freeing up a connection and thread more quickly. Most environments will benefit from allowing the Script Resource Handler to compress and cache scripts, but busy servers need to be monitored to watch out for possible negative impacts to memory or processor usage.
First, use the Internet Services Manager to go to the property pages for the web site. On the services tab, check the Compress static files check box, and specify a directory for the server to use in caching the compressed output. This saves the overhead of recompressing the content after a process restart.
The MMC snap-in does not expose one key setting that should be changed to enable compression of the .js files for both standard compression types that are supported. You have to make the change in the IIS6 metabase directly. You can use the adsutil.vbs file installed in \WINNT\System32\Inetpub\AdminScripts.
To enable IIS to use deflate and gzip compression on .js files, use the following command lines:
cscript.exe adsutil.vbs set w3svc/Filters/Compression/DEFLATE/HcFileExtensions "js" cscript.exe adsutil.vbs set w3svc/Filters/Compression/GZIP/HcFileExtensions "js"
cscript.exe adsutil.vbs enum w3svc/filters/compression/parameters
You should look at the output and consider your application variables before setting a new expiration to ensure that you are picking an appropriate expiration for your environment.
The ScriptManager control has a ScriptPath property that can be set to an absolute path to make use of a copy of the scripts shared by multiple applications and directories. This can avoid the impact of many different applications consuming additional memory to cache the scripts and bypasses the need to compress them again.
The ScriptManager uses the ScriptPath as the root location to search for scripts and takes into account the assembly name and version. If want to cache the scripts in a folder under the root of the web site, you thus need to copy them from their default location under C:\Program Files\Microsoft ASP.NET. For example, you could set the ScriptPath="/scripts" and then copy the files into C:\InetPub\wwwroot\scripts\System.Web.Extensions\1.0.61025.0\, assuming your web root folder is C:\InetPub\wwwroot.
The ScriptPath setting of the ScriptManager applies to all of the ScriptReferences that it contains. However, the ScriptReference has a Path property that can override that setting. You may be tempted to override the path directly to put the AJAX scripts in a simpler path without the version, but I recommend against it. The use of the version number identifies the scripts so that servicing and subsequent releases will use a different folder to avoid problems.
If you switch from the dynamic scripts to the static versions, you also need to be aware of a servicing concern. If the ASP.NET team releases an updated version of the scripts, you will need to update your deployed copy in order to get the fix. It will no longer be sufficient to just install the updated System.Web.Extensions.dll in the GAC.
If you install a new version of System.Web.Extensions.dll in the GAC and create a new version-coded folder to hold the scripts, you may also want to keep the old dll in the GAC and keep the old scripts in place to service older applications that haven’t been updated yet.