[wp-trac] [WordPress Trac] #11453: Use compression for CSS and JS file output

[WordPress Trac]

#11453: Use compression for CSS and JS file output
-----------------------------+----------------------------------------------
 Reporter:  micasuh          |       Owner:                              
     Type:  feature request  |      Status:  new                         
 Priority:  normal           |   Milestone:  3.0                         
Component:  Optimization     |     Version:  2.9                         
 Severity:  normal           |    Keywords:  css, js, minify, compression
-----------------------------+----------------------------------------------

Comment(by Denis-de-Bernardy):

 Being in the middle of rewriting my cache plugin at the moment, a couple
 of remarks on the idea:

 1. mod_deflate is, imo, better than a php ob_gzhandler, as discussed in
 #10365

 2. Some assets (js and css files) have arguments or are dynamic (eg,
 cookies for comments) and should not be concatenated. Retrieving assets
 that aren't inserted using the depends API is messy to say the least. In
 addition, they generally have no version, are/or are potentially dynamic,
 so should not get concatenated either.

 3. Minifying is overrated, especially when it's done on the fly. The whole
 idea is to reduce the file size, but a minified, gzipped asset is the same
 size (give or take) as a non-minified, gzipped asset. Minifying on the fly
 additionally introduces a lag, which can then lead to concurrent write
 problems (see below).

 4. Placing the concatenated assets on a Content Delivery Network (I'm sure
 someone will bring that up too) is overrated for a similar reason: placing
 the file on a CDN on the fly is an extremely messy business, and it
 introduces further lags as the page is rendered -- since it needs to be
 completed before the script or style tag is output.

 5. Generating concatenated page assets introduces all sorts of
 possibilities for concurrent writes, which means we then need to deal with
 file lock-related problem. This can significantly slow down concurrent
 page loads. (Sites that are spread over multiple servers are actually
 easier to manage here, since the assets can be placed in memcached.)

 6. Removing concatenated page assets that are no longer used is an
 extremely messy business.

 7. There needs to be a non-concatenated mode in the event a user is in the
 process of editing his site's js and css files; it should also be turned
 on by default, so as to avoid support problems ("why can't I see my
 changes?").

 8. Lastly, I suspect that the focus on speed is overhyped. Intuitively,
 google wants to eliminate spammy sites that consistently load in several
 seconds because they're aggregating data from all over the place while
 they load. I honestly doubt that they're going to penalize WP installs
 overnight -- especially considering that most of them load faster than
 Yahoo! Finance.

 In short, I suggest we close this as plugin material for now, and revisit
 the idea in a few years when the dependencies API is rock solid.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/11453#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software