[wp-trac] [WordPress Trac] #11453: Use compression for CSS and JS file output
WordPress Trac
wp-trac at lists.automattic.com
Sun Dec 20 03:40:35 UTC 2009
#11453: Use compression for CSS and JS file output
-------------------------------------------------+--------------------------
Reporter: micasuh | Owner:
Type: feature request | Status: reopened
Priority: normal | Milestone: Future Release
Component: Optimization | Version: 2.9
Severity: normal | Resolution:
Keywords: css, js, minify, compression, speed |
-------------------------------------------------+--------------------------
Comment(by micasuh):
hakre, please don't close this while we're having a big discussion. The
problem with dismissing this as a plugin is that it defeats the purpose of
the whole idea.
Replying to [comment:15 Denis-de-Bernardy]:
> Replying to [comment:14 micasuh]:
> > I'd make a guess that most Wordpress websites only contain only a
small number of both static CSS and JS files.
>
> It ultimately depends on the number of plugins you use. My own site
contains a dozen such files for each.
Yes and each site contains a variable amount of files. We can't simply
blanket everyone in the same category since it's impossible to know
everything about all installations. I run 10's of different installs of
Wordpress and many only have between 3-5 at most, even with plugins.
> > Replying to [comment:13 hakre]:
> > > I've never seen google loading my CSS and JS files and I strongly
doubt a speed-rating mechanism will rate their downloads in the future.
> > Google's new algorithm, nicknamed Caffeine, will start rollout in the
new year. Included in this newer, rebuilt search system is attention to
page speed, as indicated in the link in the ticket description.
>
> If you're so worried, here's your chance to use the Semiologic Cache or
the Total Cache plugin. Both do a good job at pruning everything and
trimming the daylights out of server requests (I'd argue that the first
does a better job than the second, but I'm obviously biased).
Using another plugin, which obviously means more external PHP requests, is
the antithesis of this idea. The purpose of building these features into
Wordpress is bypass the use of plugins, reduce the rendering load and
bring mainstream processes and forward thinking utilities to the
developer. Plugins are great, but essential processes such as minifying
and compression should not be dismissed as plugins or second rate.
> > I agree that Google spiders or bots probably won't rate download
speeds of individual files.
>
> this, I think, is where you're wrong. it will have utmost importance if
speed is the question. In particular your main page, rather than its
assets, since it determines how long it takes to display ''something''.
Okay, point taken. But this is just another argument for including this
fundamental idea into Wordpress from the get go. I think it's naive to
undervalue minification and/or compression and what it does for CMSes such
as Wordpress.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/11453#comment:18>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list