(photo by Gzip)

I envy the web apps running off apache. They get an incredible speed boost thru compression just by enabling the mod_gzip module.

Websites on AOLServer 4.5 can use ns_zlib to serve compressed adp pages but I don't know yet if static files like images, cascading style sheets or javascript can automatically be served compressed.

We've been doing lots of front end development and the size of javascript and css files can take its toll on load times. 

Just yesterday I came accross this thread from the AOLServer mailing list archives where the author shares a filter for AOLServer that he wrote to serve up gzipped content if it's available. You don't need ns_zlib to use this filter as you are expected to gzip your resources beforehand. The filter will essentially ...

• check if there is a gzipped version of the resource
  
• if a gzipped version is found it serves the gzipped content and sets the Content-Encoding header to gzip so that browsers are aware
• if there is no gzipped version, the resource file is served as is 

After studying the code, I figured that it could be potentialy useful for OpenACS projects that have a lot of javascript and cascading stylesheets.

OpenACS already has filters for files in the resource folder of packages. One colleague aptly called it "trick urls" because it conveniently allows you to point to the resource folder in a package without necessarily mounting the package. Since, a filter is already in place, I figured I could modify it a little to

• check for gzipped resource files
• set the content-encoding to gzip and serve the gzipped resource files if available 

So this is the result ...

ad_proc -private rp_resources_filter { why } {
This filter runs on all URLs of the form /resources/*.  The acs-resources package
mounts itself at /resources but we short circuit references here in order to
maximize throughput for resource files.  We just ns_returnfile the file, no
permissions are checked, the ad_conn structure is not initialized, etc.
There are two mapping possibilities:
/resources/package-key/* maps to root/packages/package-key/www/resources/*
If that fails, we map to root/www/resources/*
If the file doesn't exist we'll log an error and return filter_ok, which will allow
packages mounted at "/resources" in a legacy site to work correctly.  This is a
horrible kludge which may disappear after discussion with the gang.
@author Don Baccus (dhogaza@pacifier.com)
} {
set path "[acs_package_root_dir [lindex [ns_conn urlv] 1]]/www/resources/[join [lrange [ns_conn urlv] 2 end] /]"
if { ![file isfile $path] } {
set path "[acs_root_dir]/www/resources/[join [lrange [ns_conn urlv] 1 end] /]"
}
if { [file isfile $path] } {
if {[string first {gzip} [ns_set get [ns_conn headers] {Accept-Encoding} ] ] != -1} {
set gzfile "${path}.gz"
if {[file exists $gzfile]} {
# ns_log notice "GZIP EXISTS ***********"
ns_set put [ns_conn outputheaders] Content-Encoding gzip
ns_returnfile 200 [ns_guesstype $path] $gzfile
} else {
#ns_log notice "NO GZIP ***********"
ns_returnfile 200 [ns_guesstype $path] $path
}
} else {
ns_returnfile 200 [ns_guesstype $path] $path
}
return filter_return
} else {
ns_log Error "rp_sources_filter: file \"$path\" does not exists trying to serve as a normal request"
return filter_ok
}
}

The proc I modified is in acs-tcl/tcl/request-procs.tcl. It will only be useful if you gzip the resource file that you want to serve compressed.

For example if you have a file in /packages/ajaxhelper/www/resources/ext2/ext-all.js, you need to create a gzipped version of it in the same directory.

gzip -c ext-all.js > ext-all.js.gz

This isn't exactly mod_gzip for OpenACS but it's a good start.

So what do we need to do next ...

• Figure out if we can parameterize this. You'll want to turn this off when debugging javascript and css
• See if we can use ns_zlib to compress on the fly
• If we do get ns_zlib to compress on the fly, it'll probably be a good idea to have a mechanism that caches the compressed resource file for future requests as opposed to compressing every time.
• The caching mechanism will need to be smart to determine if the file size of the original resource file has changed and to request a new compressed version.

After implementing the change in the request processor and gzipping the css and js files, I found at least a 40% to 50% speed boost in my tests when viewing pages with heavy css and javscript files with browser caching turned off.

In our Friend Webs facebook application, initial load time of javascript according to firebug, with no caching, is about 30 seconds. Ouch ! With the changes above and gzipped resource files in place, firebug reports that the javascript loads in just under 15 seconds !