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 |
horde, and lighttpd/mod_compress has very decent approach.
Ticket can be closed.
State ⇒ Rejected
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.
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?
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.
[the file] ... the WEBSERVER checks...." This is by no means the
default action for webservers and requires additional configuration.
created, however this is not true exactly true for javascript/css
files, which are created once but delivered several times.
known until someone accesses that page for the first time, just like
the javascript files.
single administrator to find ways to compress the .js/.css files
from static/ .
I recommend you look at lighttpd and the mod_compress module,
specifically compress-cachedir, which does all this compression
transparently.
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/ .
Priority ⇒ 1. Low
State ⇒ Feedback
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.
This can't happen because the payload for any given page is not known
until the page is created.
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.
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.
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.
can control out of the box.
http://www.horde.org/apps/horde/docs/PERFORMANCE , or write some
alternative text to enable serving of pre-compression files on the
webserver.
servers (e.g. lighttpd) cache the gzip'd versions, but this is beyond
the scope of Horde or Horde's configuration.
Priority ⇒ 2. Medium
Type ⇒ Enhancement
Summary ⇒ precompress files in /static
Queue ⇒ Horde Base
Milestone ⇒
Patch ⇒ No
State ⇒ New
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.