Reading around on the web about this, there is some concern that some browsers may not like compressed js and/or css.  It sounds like mostly older browsers, and perhaps IE6 when used through certain kinds of proxies (the trick being that IE6 doesn't support compressed css/js over HTTP/1.0 which these proxies force the protocol down to?).

This needs more investigation about compatibility first.

Really compression is just one part of a larger picture: optimizing our page load times.  I've read some great info from Yahoo's presentations on the subject, and distilled that a bit into some practical measures we could make use of without getting too crazy.  So here comes the list.  A lot of these suggestions that involve mucking with css/js files would of course involve us generating them with a tool when they're modified, so that we can continue to work on the originals in their normal form.

SN webdev issues (can be solved purely in the sn web code repo)
=================

1) Where possible, combine multiple javascript or css files into a single file.  If file a is always loaded with file b, combine a+b into one file.

3) Compress javascripts with a js minify/obfuscate script.  Strips whitespace, renames variables to short names, etc.

4) Use "CSS Sprites" to combine several images that are always used together on the same page into a single image file for the browser to load (Google it).

5) Don't load the same script twice from different areas of the page (I don't know if we do this know, but we should audit for it).

6) For any scripts that don't contain direct page-modifying code (like document.write()) in the outer scope (and aren't dependencies of those that do), move the <script> tag to the end of the page rather than the top of the page.

7) Make sure all CSS is included in the HEAD section.

8) Prefer additional HEAD-time css <link>'s to @import

9) Get rid of CSS Expressions if we're using them.  We have some inexplicable (to me) uses of this in userForm.css, probably part of a mechanism for hiding the values from non-IE browsers.  There are probably other ways.

10) Find a way to get Catalyst+TT to flush the head of the page before trying to serve the dynamic parts.  If you get the HEAD part (+js/+css) out to the browser quickly, it can get useful stuff done while you're still hitting the DB to generate the rest of the page.

11) Get rid of external redirects where possible (as in, replace actual 3xx redirects with Catalyst internal redirects everywhere we can get away with it).

12) Convert all of our gif's to pngs, and run them through pngcrush with maximal settings to minify them.  Use a tool to strip any extraneous data (like comments) from jpegs.

Lighttpd-level issues (more at the Operations level)
======================

1) Compress (as in gzip/deflate) css/js content at the webserver (we have the capability, but we need to investigate any lingering compatibility issues with older http caches - Yahoo claims the number of noncompliant ones is rapidly dwindling and it may no longer be a big issue).

2) Add expires headers to common static data (images, scripts, stylesheets), giving it a lifetime of at least a few minutes.  We could use ultra-long lifetimes too, but that would involve embedding version numbers into the filenames.

3) Investigate ETag usage - either make it work globally or disable it completely, anything inbetween is a performance waste.

4) Get rid of useless redirects that come from trailing slashes (rewrite http://.../foo/ as http://.../foo internally).

(In reply to comment #2)
> 4) Get rid of useless redirects that come from trailing slashes (rewrite
> http://.../foo/ as http://.../foo internally).

I always thought it was the other way 'round.  If you intend .../foo to serve the index page from the directory 'foo' then with the trailing slash, the http server knows that it's a directory reference.  Without it, the server first treats it as a file reference and redirects the browswer if there's a directory of the same name.

Thanks! Excellent information in this list.

> 1) Where possible, combine multiple javascript or css files into a single file.
>  If file a is always loaded with file b, combine a+b into one file.

Doing this using TT isn't the right way to go, is it? Might improve load time on the client side at the cost of server load.

> 4) Use "CSS Sprites" to combine several images that are always used together on
> the same page into a single image file for the browser to load (Google it).

We're doing this in SC - reduced the number of artwork files considerably.

> 5) Don't load the same script twice from different areas of the page (I don't
> know if we do this know, but we should audit for it).

We do in SC: we load the JS libraries from inside the left-hand side frame again. I wonder whether an initial script should/could walk up the document tree and hook into another copy if it can find one.

> 9) Get rid of CSS Expressions if we're using them.  We have some inexplicable
> (to me) uses of this in userForm.css, probably part of a mechanism for hiding
> the values from non-IE browsers.  There are probably other ways.

If it's inexplicible, then it's IE related. I added a few of them myself (SN only, we're fine in SC with a separate stylesheet...) to work around IE issues.

> 12) Convert all of our gif's to pngs, and run them through pngcrush with
> maximal settings to minify them.  Use a tool to strip any extraneous data (like
> comments) from jpegs.

IE6 anyone? We have (too much) code in SC taking care of the IE6 laggers (like Logitech employees ;-)), as IE6 doesn't support transparency. There are some JS libraries which can fake transparency using some activex trickery, but they didn't work with our layout. We've tested 2-3 of those.

Hi,

Just wanted to re-invigorate this discussion. ReadyNAS Duo's web performance would benefit from any small around of optimisations. YSlow is identifying some items needing to be addressed.

GZIP/Compression is actually not a great idea as the most people will be accessing SC from an internal network so latency is more of an issue than bandwidth. So really GZIP off is better as much less server load.

For me the 3 key areas to focus on are:

1. Combining the CSS files into one (same with JS) , or even including in the HTML would make a big difference. I also note that the JS and CSS files urls include a random number - this is obviously to override caching - this seems unnecessary, and will also not allow for any type of server or client side caching. If there are issues with cached versions of CSS/JS files with upgrades to SC then those files themselves should be versioned in the name or path with build number(ie skin_27044.css or 27044\skin.css) which would occur at compilation time.

2. This would also allow for future expires on these items, and others. YSlow reports a few other files in need of this treatment. Favicon is important too, as it gets requested every time the page is loaded - this should certainly have a far future expires.

3. The last item to be addressed would be for a better utilisation of CSS spriting, and perhaps even moving some of the rounded corner work to CSS (let IE6/7 eat square cake).

There is also the possibility of using another port for other requests instead of subdomains to increase the concurrent requests, but once again I'm not sure this is is actually beneficial for low-powered CPUs like the SPARC.

I'm happy/keen to make some modifications to the default skin and submit/record the changes if that's helpful/possible. Even just building the CSS sprites. There is an opensource (albeit PHP) toolchain that can do this automatically (https://launchpad.net/css-sprite-generator/).

Cheers,

Ross