6.0.0-alpha12
6/12/25

[#11017] precompress files in /static
Summary precompress files in /static
Queue Horde Base
Queue Version 4.0.13
Type Enhancement
State Rejected
Priority 1. Low
Owners
Requester dpa-bugs (at) aegee (dot) org
Created 02/21/2012 (4860 days ago)
Due
Updated 03/04/2012 (4848 days ago)
Assigned
Resolved 02/21/2012 (4860 days ago)
Milestone
Patch No

History
03/04/2012 02:41:11 PM dpa-bugs (at) aegee (dot) org Comment #5 Reply to this comment
I agree that the compression can be addressed by the webserver, not in 
horde, and lighttpd/mod_compress has very decent approach.

Ticket can be closed.
02/21/2012 09:58:30 PM Michael Slusarz Comment #4
State ⇒ Rejected
Reply to this comment
With pre-compression I mean to extend Horde to create for each 
static/f.js a corresponding static/f.js.gz and for each static/k.css 
a corresponding static/k.css.gz file at the same time the original 
file (without .gz) is created.
Why?  What good is a *.gz file unless the *web server* delivers it as 
such.  You can't just place a .gz file in a directory and expect a 
webserver to use that when the base file is accessed.  This demands 
additional configuration on the webserver, so putting an option in 
horde's conf.php that doesn't do anything by default on is not 
desirable.  Especially when there are other options available on the 
webserver side that does this all transparently.  Why configure 2 
locations when you only have to configure 1?
When a browser requests static/m.js and does Accept-Encoding: gzip, 
the webserver checks if static/m.js.gz exists, and sends 
static/m.js.gz to the browser,(instead static/m.js)  stating the 
response is gzip-encoded.
And you just proved my point.  As you write "When a browser requests 
[the file] ... the WEBSERVER checks...."  This is by no means the 
default action for webservers and requires additional configuration.
I know the payload for any html page is not known until the page is 
created, however this is not true exactly true for javascript/css 
files, which are created once but delivered several times.
This is an incorrect statement.  The CSS for any given page is not 
known until someone accesses that page for the first time, just like 
the javascript files.
I think this functionality belongs to Horde and it is not up to each 
single administrator to find ways to compress the .js/.css files 
from static/ .
Disagree.

I recommend you look at lighttpd and the mod_compress module, 
specifically compress-cachedir, which does all this compression 
transparently.
02/21/2012 09:01:44 AM dpa-bugs (at) aegee (dot) org Comment #3 Reply to this comment
With pre-compression I mean to extend Horde to create for each 
static/f.js a corresponding static/f.js.gz and for each static/k.css a 
corresponding static/k.css.gz file at the same time the original file 
(without .gz) is created.

When a browser requests static/m.js and does Accept-Encoding: gzip, 
the webserver checks if static/m.js.gz exists, and sends 
static/m.js.gz to the browser,(instead static/m.js)  stating the 
response is gzip-encoded.

I know the payload for any html page is not known until the page is 
created, however this is not true exactly true for javascript/css 
files, which are created once but delivered several times.

I think this functionality belongs to Horde and it is not up to each 
single administrator to find ways to compress the .js/.css files from 
static/ .
02/21/2012 03:17:03 AM Michael Slusarz Comment #2
Priority ⇒ 1. Low
State ⇒ Feedback
Reply to this comment
In static/ are put the minified .js and .css files, which are sent 
to the user's browser.  If the webserver is configured properly, the 
minified .js/.css files are cached on the user's side and the server 
load on subsequent requests is minified this way.  So far so good.

Another possible optimization is to pre-compress the files in 
/static, so that for each file a .js/css plain and .js.gz/.css.gz 
version exists.
Do you mean automatically creating the files to then compress them?   
This can't happen because the payload for any given page is not known 
until the page is created.
The instructions for some webservers, how to call the precompressed 
files vary.  For Apache httpd you can find instructions that procees 
.gzip files, for Nginx you have just to say "gzip_static on;" and 
the server starts preferring files with .js.gz extenstion and when a 
file .js is requested.
We **really** don't want to get into the business of trying to track 
the ways various httpd servers can compress data.  I wouldn't mind a 1 
or 2 sentence blurb on this in PERFORMANCE, but we are not going to 
provide individual examples.  That is up to the server admin to figure 
out.

If others want to provide real-life examples on the wiki, that is the 
more appropriate place to put this information since it is not 
directly Horde-related.
Please extend the Horde configuration to ask the site 
adminsitrators, if they want to have in /static pre-compressed .js 
and .css files, and if yes, if they want .gzip or .gz extension for 
those files. (or just create the .gz files in addition to the rest 
and that's all.
This is not a Horde configuration issue, since it is not something we 
can control out of the box.
Please mention this bug in 
http://www.horde.org/apps/horde/docs/PERFORMANCE , or write some 
alternative text to enable serving of pre-compression files on the 
webserver.
Still don't know what you mean by "pre-compression".  I know certain 
servers (e.g. lighttpd) cache the gzip'd versions, but this is beyond 
the scope of Horde or Horde's configuration.
02/21/2012 12:45:01 AM dpa-bugs (at) aegee (dot) org Comment #1
Priority ⇒ 2. Medium
Type ⇒ Enhancement
Summary ⇒ precompress files in /static
Queue ⇒ Horde Base
Milestone ⇒
Patch ⇒ No
State ⇒ New
Reply to this comment
In static/ are put the minified .js and .css files, which are sent to 
the user's browser.  If the webserver is configured properly, the 
minified .js/.css files are cached on the user's side and the server 
load on subsequent requests is minified this way.  So far so good.

Another possible optimization is to pre-compress the files in /static, 
so that for each file a .js/css plain and .js.gz/.css.gz version 
exists.  With proper configuration of the webserver, when the client 
ACCEPTs-ENCODING: GZIP, the webserver can check if there is a 
pre-compressed file and sent it to the client, instead of sending 
uncompressed file or compressing everytime the same files on the fly.   
This leads to lower network traffic, lower server load, faster page 
serving from user's perspective.

The instructions for some webservers, how to call the precompressed 
files vary.  For Apache httpd you can find instructions that procees 
.gzip files, for Nginx you have just to say "gzip_static on;" and the 
server starts preferring files with .js.gz extenstion and when a file 
.js is requested.

Please extend the Horde configuration to ask the site adminsitrators, 
if they want to have in /static pre-compressed .js and .css files, and 
if yes, if they want .gzip or .gz extension for those files. (or just 
create the .gz files in addition to the rest and that's all.

Please mention this bug in 
http://www.horde.org/apps/horde/docs/PERFORMANCE , or write some 
alternative text to enable serving of pre-compression files on the 
webserver.

Saved Queries