[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