Redmine

Pablo Quiroga wrote:

• First, there are too many http requests. Most of them are small images. We could use the sprite technique [1], so instead of loading a bunch of files, we load just one image and use css to put the images in the right place using background-position property.

HTTP 1.1 connection reuse nearly nullifies any load overhead caused by many file requests, and I think spriting will just make it needlessly complicated to maintain.

• There are 5 js and 2 css files, uncompressed and unminified. The solution may be a minifier/gzipper like this one [2] (written in php, but can be ported). It dynamically combines, minifies and compress js and css files. The average compression rate is about 60-70%.
• Optimize and compress html output. Maybe is not as important as other resources, but the save could be between 50-60%.

Compression is in my opinion something the server frontend should manage, not the app. I have configured apache to deflate text content (html, xml, css, js), works a charm.

• Leverage cache for resources.

That is a built-in feature of rails: static resources are appended with a timestamp so that you can set their cache-expire somewhere far in the future and still have clients pick up the changes when you really change the files. Again, the cache-expire is to be handled by the frontend server, my apache installation sets the expire header of images, css and js files one year into the future, no problems so far.

• Loseless Optimization of png images by recompressing data [3]

IIRC this has already been done a few weeks ago.

Anyway, the number of files and their "optimization" or "minification" is irrelevant if you set your expire headers properly: clients only download the html after first load on my installation, so their number and "size" are not that much of a problem.

• Avoid css expressions.
• Put css before js resources.

I would like to contribute to optimize redmine frontend. I wait for your comments.

The best way to contribute is to submit patches, more info on the Contribute page.

Felix Schäfer wrote:

Pablo Quiroga wrote:

• First, there are too many http requests. Most of them are small images. We could use the sprite technique [1], so instead of loading a bunch of files, we load just one image and use css to put the images in the right place using background-position property.

HTTP 1.1 connection reuse nearly nullifies any load overhead caused by many file requests, and I think spriting will just make it needlessly complicated to maintain.

I don't think it will be hard to maintain. Anyways, I can rewrite the default skin using an sprited icon set, and see if it's really usefull.

• There are 5 js and 2 css files, uncompressed and unminified. The solution may be a minifier/gzipper like this one [2] (written in php, but can be ported). It dynamically combines, minifies and compress js and css files. The average compression rate is about 60-70%.
• Optimize and compress html output. Maybe is not as important as other resources, but the save could be between 50-60%.

Compression is in my opinion something the server frontend should manage, not the app. I have configured apache to deflate text content (html, xml, css, js), works a charm.

I agree. I've done that also and it's ok. But maybe this option could be included in the .htaccess file commented. But as I said before, minify and compress js and css files is a big deal. Just for prototype.js the size drops from 126.7kb to 21.4kb (83,1%) and that's a pretty good size reduction.

• Leverage cache for resources.

That is a built-in feature of rails: static resources are appended with a timestamp so that you can set their cache-expire somewhere far in the future and still have clients pick up the changes when you really change the files. Again, the cache-expire is to be handled by the frontend server, my apache installation sets the expire header of images, css and js files one year into the future, no problems so far.

Again, this optimization could be on the .htaccess file.

• Loseless Optimization of png images by recompressing data [3]

IIRC this has already been done a few weeks ago.

Ok, just I have the report of PageSpeed telling me that some image can still be optimized.

Anyway, the number of files and their "optimization" or "minification" is irrelevant if you set your expire headers properly: clients only download the html after first load on my installation, so their number and "size" are not that much of a problem.

• Avoid css expressions.
• Put css before js resources.

I would like to contribute to optimize redmine frontend. I wait for your comments.

The best way to contribute is to submit patches, more info on the Contribute page.

Thanks.

Reply copied from Mathias Goldau's post Can reply to http://www.redmine.org/boards/1/topics/13340...:

Pablo Quiroga wrote:

Felix Schäfer wrote:

Pablo Quiroga wrote:

• There are 5 js and 2 css files, uncompressed and unminified. The solution may be a minifier/gzipper like this one [2] (written in php, but can be ported). It dynamically combines, minifies and compress js and css files. The average compression rate is about 60-70%.
• Optimize and compress html output. Maybe is not as important as other resources, but the save could be between 50-60%.

Compression is in my opinion something the server frontend should manage, not the app. I have configured apache to deflate text content (html, xml, css, js), works a charm.

I agree. I've done that also and it's ok. But maybe this option could be included in the .htaccess file commented. But as I said before, minify and compress js and css files is a big deal. Just for prototype.js the size drops from 126.7kb to 21.4kb (83,1%) and that's a pretty good size reduction.

I just partially agree with that. Of course gzipping is the job of the server as e.g. apache, but you could save a lot more. I tested a javascript compressor on prototype.js of redmine 1.1.3. It resulted in

Original Size: 159.49KB (36.57KB gzipped)
Compiled Size: 84.92KB (25.79KB gzipped)
Saved 46.76% off the original size (29.47% off the gzipped size)

meaning, if you "compress and optimize" before gzipping, than you could save much traffic since awstats tells me that 9% of the traffic of my redmine instance is related to javascript. I would recommend googles compressor: http://closure-compiler.appspot.com/home since it was rated high on http://stackoverflow.com/questions/28932/best-javascript-compressor