Javascript and CSS compression design

[Joonas Lehtinen]

On what level should JS and CSS compression be implemented?

On Apache Tomcat, this works just fine

    <Connector port="8080" maxHttpHeaderSize="8192"
               maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               connectionTimeout="20000" disableUploadTimeout="true"
                           compression="on" 
			   compressionMinSize="2048" 
			   noCompressionUserAgents="gozilla, traviata" 
			   compressableMimeType="application/xml,text/html,text/xml,application/x-javascript,text/css,text/javascript"
     />

In fact, it even compresses UIDL transparently.

Question is:

• Should we implement compression by ourshelves?
• Should we compress UIDL (or JSON)

[Jani Laakso]

Mikael, please check with me if we could activate compression for Toolkit production site. This has huge benefits for Mobile users and some for standard Browsers.

[Jani Laakso]

Please check how to enable this for Toolkit production site. Tell me status of this ticket before 7.3.2007, thanks.

[Mikael Vappula]

Due to restrictions on production site environment (Apache http 1.3x) js & css compression is implemented by an ancient mod_gzip module since compression on Tomcat side + apache proxy didn't work and Tomcat ajp-connector has no compression support.

I compiled the module from sources (http://schroepl.net/projekte/mod_gzip) for this particular apache instance.

UIDL won't get compressed, maybe a mod_gzip/mime-type configuration issue.

[Joonas Lehtinen]

This is great - now js (which was the largest problem) transfertime is only about 30% of the past. Many thanks to Mikael!

[Joonas Lehtinen]

Also tested on Nokia E70. Startup time and responsivity on calculator demo is great when compared to the past (through 3G).

[Jani Laakso]

Thanks, good work Mikael!