Resource Compression

Overview

In production systems, it's often desirable to reduce network bandwidth usage by compressing certain types of resources provided from the server. Typically this means that the client indicates via HTTP headers what it will accept. For example:

Accept-Encoding:gzip

When properly configured, the server, for applicable content types, will compress those resources before sending them back to the client.

As of ICEfaces 3.1, the core framework and components no longer do any compression of HTTP responses by default. Instead, it is recommended that compression be handled either through:

configuration of the server platform your application is deployed to
configuration of the JSF implementation your application is running on

Configuring Compression on the Server Platform

The recommended option is to let your container or web server handle the compression. Nearly every server has a mechanism to provide and configure compression on the responses:

Tomcat 6 and 7

In Tomcat, compression is off by default but you can set one or more attributes of the HttpConnector (compression, compressableMimeType, compressionMinSize) to control what type and size of file gets compressed.

Tomcat 6 HTTP Connector Configuration
Tomcat 7 HTTP Connector Configuration

Apache 2.x

If you are using Apache HTTP server as a front end for your server or cluster, you can configure Apache to do the compression. The mod_deflate module documentation is here:

Apache mod_deflate Module Documentation

WebSphere Platforms

In general, compression in WebSphere is accomplished using IHS (IBM HTTP Server) which is a dedicated web server that sits in front of a WebSphere server or cluster. Since IHS is basically a re-packaged version of Apache, you can use the same mod_deflate module configuration as outlined in the Apache documentation:

IHS mod_deflate Module Documentation

WebLogic Platforms

WebLogic doesn't provide any built-in compression settings. A common solution is to use Apache as noted above or deploy a compression filter as described below.

Custom Compression Filter

If the platform you are running on doesn't provide built-in compression or you want more control over the compression yourself, you always have the option to write your own servlet filter which can do the required compression on whichever content types you decide. Or you could download a third-party filter. There is a wealth of information on the web on this topic.

Essentials of Filters

Configuring Compression with JSF

No compression in Development mode

In both Mojarra and MyFaces, if the project stage is set to Development, then no compression will occur. However, this only applies to JSF's compression, not compression accomplished through other means.

    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
    </context-param>

Mojarra

With Mojarra, compression can be done with a context parameter and specifying the desired content types to compress:

    <context-param>
        <param-name>com.sun.faces.compressableMimeTypes</param-name>
        <param-value>text/css</param-value>
    </context-param>

The list of types is comma separated and supports the wildcard character ('*'). More information is available by following:

Mojarra 2 Release Notes
JBoss Reference to Mojarra Context Params

MyFaces

With the MyFaces implementation, configuring compression is a bit more involved than it is with Mojarra. You need to add the MyFaces Commons library:

MyFaces Commons Resource Handler

and then set one or more context parameters as outlined in the documentation:

MyFaces Resource Handler Parameters

History of Resource Compression in ICEfaces

The strategy for compressing resources in ICEfaces has changed from previous versions. In ICEfaces 1.x, we typically compressed nearly all of the resources we served ourselves, with the behaviour being modified though the use of a context parameter (see compressResources):

    <context-param>
        <param-name>com.icesoft.faces.compressResources</param-name>
        <param-value>false</param-value>
    </context-param>

With ICEfaces 2.x and above, the context parameter remains, although changed to reflect the packaging changes in the product:

    <context-param>
        <param-name>org.icefaces.compressResources</param-name>
        <param-value>false</param-value>
    </context-param>

However, with with ICEfaces 2.x and above, the compression only applies to a subset of the resources served. This includes the compat resources served via CompatResourceServlet as well as any resources added to the ResourceRegistry via methods like addSessionResource(Resource resource). This is typically done in certain components (File Entry, Data Exporter) and can also be used by application code.

There are a couple of different issues with this approach. One is that it's inconsistent. Some resources, as noted above, are compressed by ICEfaces and some (like jsf.js or bridge.js) are not compressed by ICEfaces at all. Another potential problem is that, since it's on by default and only some resources are compressed, it's possible that those resources could also be compressed by handlers other than ICEfaces. The portlet container Liferay is an example where certain resources are compressed by default. Since the compression handling overlaps it can lead to double-compression (both Liferay and ICEfaces compressing the same file) and double-compressed files are not handled well by most browsers.

Going forward, our recommendation is to rely on the tools provided by your server platform or the features provided in your JSF implementation to handle your compression requirements so that the behaviour is consistent and predictable.