Back in 1993 I read about a game called DOOM that I felt I needed to play immediately. My parents had a computer with a 14.4 modem and I conspired to find a BBS located in some other state. I managed to connect and over the next few hours DOOM trickled across the wire to my computer. A few weeks later I had to explain the phone bill to my parents.
Thankfully we’ve come a long way since those days. Internet response times are measured in milliseconds, not hours. A variety of strategies can be used to reduce page-load times. In addition, there are wonderful tools that can be used to guide our optimization efforts.
One of those tools is a Firefox add-on called YSlow. YSlow analyzes web pages and suggests ways to improve performance based on a set of rules for high performance web pages.
Compress Components with GZip
I recently set aside some time to tune Sitefinity Watch. YSlow wasn’t very impressed with my efforts thus far and gave me a failing grade. I started working through YSlow’s list of complaints. One of the first items I focused on was compression.
All modern browsers support gzip compression; this allows content to be compressed on the server before it’s transferred to the client (browser). Using HTTP compression:
- Reduces - bandwidth usage and transfer times.
- Increases - the CPU demands on both the server and the client (content must be compressed and then uncompressed).
Often this is considered a reasonable tradeoff, but you should consider your own situation. From Microsoft:
Not ideal situations to enable HTTP Compression:
High % Processor Time counter: If the % Processor Time counter is already 80 percent or higher, HTTP Compression is not recommended unless you can upgrade the server's CPU.
Dynamic content: If a large volume of dynamic content is generated on your server, enabling HTTP Compression for application files results in higher processor usage. Because dynamic content is not cached, it must be re-compressed each time it is requested by a client.
Inadequate disk space: If the server does not have available disk space to store the compressed files, then don't enable HTTP Compression until more hard-drive space can be added to your server.
Enabling HTTP Compression for Sitefinity
HTTP compression can be enabled by adding a few lines of code to the global.asax file.
However, this technique will only compress content that is processed by ASP.NET. Content not processed by ASP.NET (css, js, html, txt, etc.) will continue to be uncompressed.
The best way to ensure all content is compressed is to enable HTTP compression in IIS. Sitefinity community member Aashish wrote a wonderful blog post describing how to compress dynamic content in IIS 6. Another wonderful post on this topic can be found here and here.
Follow the instructions found in Aashish’s post. Be sure to add all the Sitefinity related dynamic extensions to the C:\Windows\System32\Inetsrv\Metabase.xml:
<IIsCompressionScheme Location ="/LM/W3SVC/Filters/Compression/gzip"
HcCompressionDll="%windir%\system32\inetsrv\gzip.dll"
HcCreateFlags="1"
HcDoDynamicCompression="TRUE"
HcDoOnDemandCompression="TRUE"
HcDoStaticCompression="TRUE"
HcDynamicCompressionLevel="0"
HcFileExtensions="htm
html
css
js
txt"
HcOnDemandCompLevel="10"
HcPriority="1"
HcScriptFileExtensions="asp
aspx
axd
dll
exe"
>
</IIsCompressionScheme>
After making these changes, the World Wide Web Publishing Service (IIS) might need restarted.
YSlow can now be re-run to check the new results. I’m now one step closer to having an A grade.
** Thanks Aashish for writing this post. Writing setup instructions takes a lot of time. Taking screenshots and creating illustrations takes even more time. Your efforts are truly appreciated!
