Introduction
There have been many instances where we have struggled to increase performance of the web site because in practical situation, applications become very complex with tons of JavaScripts and huge CSS files and downloading that information takes time if the bandwidth is low. Here we can increase the performance using the ideas below without changing any code.
Background
Here I am trying to present some ideas which are being used these days but still many don't know. I will be covering 2 ways of compressing the contents in web applications.
- Compression/ Minification of JavaScript and CSS
- IIS Compression
I have also mentioned links from where I got the information and in here I am trying to show a brief of the same.
1. Compression/ Minification of JavaScript and CSS
Improving the engineering design of a page or a web application usually yields the biggest savings and that should always be a primary strategy. With the right design in place, there are many secondary strategies for improving performance such as minification of the code.
The goal of JavaScript and CSS minification is always to preserve the operational qualities of the code while reducing its overall byte footprint (both in raw terms and after gzipping, as most JavaScript and CSS served from production web servers is gzipped as part of the HTTP protocol). The YUI Compressor is JavaScript minifier designed to be 100% safe and yield a higher compression ratio than most other tools.
The YUI Compressor is written in Java (requires Java >= 1.4) and relies on Rhino to tokenize the source JavaScript file. It starts by analyzing the source JavaScript file to understand how it is structured. It then prints out the token stream, omitting as many white space characters as possible, and replacing all local symbols by a 1 (or 2, or 3) letter symbol wherever such a substitution is appropriate (in the face of evil features such as with
, the YUI Compressor takes a defensive approach by not obfuscating any of the scopes containing the evil statement). The CSS compression algorithm uses a set of finely tuned regular expressions to compress the source CSS file. The YUI Compressor is open-source, so don't hesitate to look at the code to understand exactly how it works.
The following command line will minify the file myfile.js and output the file myfile-min.js.
java -jar yuicompressor.jar myfile.js -o myfile-min.js
As this is a command line utility, you can always create a Nant target and automate the compression process by writing the following script:
<target name="yuicompress"
description="compresses all CSS and JS resources for the specified directory">
<foreach item="File" in="${arg.dir.in}" property="file">
<echo message="Compressing: ${file}"/>
<exec program="java" if="${string::ends-with(file, '.js') or
string::ends-with(file, '.css')}">
<arg value="-jar"/>
<arg value="yuicompressor-2.3.5.jar"/>
<arg value="${file}"/>
-->
<arg value="-o" if="${property::exists('arg.dir.out')}"/>
<arg value="${arg.dir.out}\${path::get-file-name(file)}"
if="${property::exists('arg.dir.out')}"/>
</exec>
</foreach>
</target>
2. IIS Compression
If your Web sites use large amounts of bandwidth or if you want to use bandwidth more effectively, consider enabling HTTP compression, which provides faster transmission times between IIS and compression-enabled browsers regardless of whether your content is served from local storage or a UNC resource. If your network bandwidth is restricted, HTTP compression can be beneficial unless your processor usage is already very high.
IIS provides the following compression options:
- Static files only
- Dynamic application responses only
- Both static files and dynamic application responses
Dynamic processing can affect CPU resources because IIS does not cache compressed versions of dynamic output. If compression is enabled for dynamic responses and IIS receives a request for a file that contains dynamic content, the response that IIS sends is compressed every time it is requested. Because dynamic compression consumes considerable CPU time and memory resources, use it only on servers that have slow network connections but CPU time to spare.
Compressed static responses can be cached and therefore do not affect CPU resources like dynamic responses do.
Compressed files download faster, which makes them particularly beneficial to the performance of any browser that uses a network connection with restricted bandwidth (a modem connection, for example).
Change the level of compression for static or dynamic files. Compression levels range from 0 through 10. Higher compression levels produce smaller compressed files but use more CPU and memory. Lower compression levels produce slightly larger compressed files, but with less impact on CPU and memory usage. To configure a compression level other than 10 for static files and other than zero for dynamic files, edit the HcOnDemandCompLevel
and HcDynamicCompressionLevel
metabase properties.
For dynamic compression, increasing the compression level can significantly increase CPU usage. The default compression level of zero uses the least amount of CPU resources and can increase performance if network bandwidth is adequate. Raise the dynamic compression level above zero only if you need more network bandwidth and have sufficient CPU capacity to handle the extra load.
When the Web server handles a request with a request header of "Accept-Encoding:
" it has a choice, either to send a compressed page or a standard non-compressed page. If the Web server decides to send a compressed page, it responds with a response header called "Content-Encoded:
" and the type of encoding as the value. For example, "Content-Encoded: gzip
". The browser uses this header to determine if the content is encoded and decompresses it before rendering it to the user.
Compression Strategies
When the CPU of your server is not heavily loaded, the simplest compression strategy is to enable static and dynamic compression for all of the sites and site elements (directories and files) on the server. This is known as global HTTP compression. However, when the CPU load of your server is high, you might not want to enable compression for all of the sites and site elements on the server.
Depending on CPU usage, there are two strategies for fine tuning which sites and site elements are compressed:
- Enable compression globally, and then disable compression selectively for specific sites or site elements.
- Leave global compression disabled, and then enable compression selectively for specific sites or site elements.
Following are optimal settings for IIS compression:
<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/deflate"
HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
HcCreateFlags="0"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="9"
HcFileExtensions="htm html xml css txt rdf js"
HcOnDemandCompLevel="9"
HcPriority="1"
HcScriptFileExtensions="asp cgi exe dll aspx asmx" >
</IIsCompressionScheme>
<IIsCompressionScheme Location "/LM/W3SVC/Filters/Compression/gzip"
HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
HcCreateFlags="1"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="9"
HcFileExtensions="htm html xml css txt rdf js"
HcOnDemandCompLevel="9"
HcPriority="1"
HcScriptFileExtensions="asp cgi exe dll aspx asmx" >
</IIsCompressionScheme>
<IIsCompressionSchemes Location "/LM/W3SVC/Filters/Compression/Parameters"
HcCacheControlHeader="max-age=86400"
HcCompressionBufferSize="8192"
HcCompressionDirectory="%windir%\IIS Temporary Compressed Files"
HcDoDiskSpaceLimiting="FALSE"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcExpiresHeader="Wed, 01 Jan 1997 12:00:00 GMT"
HcFilesDeletedPerDiskFree="256"
HcIoBufferSize="8192"
HcMaxDiskSpaceUsage="99614720"
HcMaxQueueLength="1000"
HcMinFileSizeForComp="1"
HcNoCompressionForHttp10="FALSE"
HcNoCompressionForProxies="FALSE"
HcNoCompressionForRange="FALSE"
HcSendCacheHeaders="FALSE" >
</IIsCompressionSchemes>
History
- 4th June, 2009: Initial post