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

WordPress Trac wp-trac at lists.automattic.com
Wed Dec 16 10:21:16 UTC 2009


#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 micasuh):

 Thanks for the great feedback. My knowledge is not as extensive as yours
 but I have a few comments.

 Replying to [comment:3 Denis-de-Bernardy]:
 > 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).
 I disagree that minifying is overrated, but I won't sit here and claim
 it's going to reduce a website by 80 or 90%.

 Minifying CSS and JS, [http://www.phpied.com/reducing-tpayload/ backed up
 by a recent report], does make a double digit percentage effect on load
 time. If we were talking about 1-9% effect, I would agree with your
 argument.

 When I refered to on-the-fly compression, I was only referring to using
 the online YUI compressor. I agree that having a continuous, on-the-fly
 compressor in Wordpress would be hazardous and would introduce a new lag
 that isn't needed.

 CSS and JS compression could be handled in one of two ways:

 1. As a button you could press in the Editor to create compressed files
 that are immediately cached. These cached files would then become the
 client-side files downloaded by visitors.

 2. When editing or saving CSS/JS in the Editor, you could choose an option
 to compress and cache a new version of these files and deliver them to
 client-side requests.

 [comment:3 Denis-de-Bernardy]:
 > 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.
 CDNs, while theoretically sound, are too immature as a technology to rely
 on for offloading requests. I agree with you on this one.

 [comment:3 Denis-de-Bernardy]:
 > 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.
 I suspect we really won't see Google Caffeine's algorithm (and similar-
 type changes on competing search engines) to immediately affect search
 results. But, as I keep hearing from Matt Cutts, Google's official blog
 and SEO websites, these results could have a great impact on results.
 Thus, WP sites that use tens of plugins are going to suffer from lags and
 slow page loads due to increased http and php requests.

 While I know Wordpress is still a blogging system at heart, it's
 increasingly being used as a CMS by folks like me and I realize how much
 bloat adding tons of plugins can cause to decrease page speed and
 rendering times.

 Wordpress can continue its dominance against even major CMS competitors by
 taking these issues seriously and promoting best practices with
 integration for speed and reliability. It's for these reasons why I hope
 this doesn't just get dismissed as a plugin or for future consideration.

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


More information about the wp-trac mailing list