[wp-hackers] compression and caching

Peter Westwood peter.westwood at ftwr.co.uk
Tue Dec 29 08:43:31 UTC 2009


On 29 Dec 2009, at 04:49, Weston Ruter wrote:

> I just read most of the messages in this thread, and I see most of  
> them are
> debating the merits of compressing (gzipping) responses. Regarding  
> scripts
> alone, just concatenating the enqueued scripts and minifying them will
> result in drastic speedups without gzipping at all. For example, I  
> recently
> a WordPress site built by a reputable company that had 50(!) external
> JavaScript files. If these were all concatenated together and
> minified/optimized, then there would potentially be only one  
> download. As an
> added bonus, this optimized script could be gzipped and even more
> importantly be served with a far-future expires header.
>

This sounds like very good site specific optimisation that a plugin  
can provide and hilights that a plugin /can/ provide it.

However, it is very easy to create a solution which optimises the  
performance of one site but actually ruins the performance of another.

I am also unconvinced about the concatenation of script files on the  
front end of a site.

If you have different js requirements for different pages you either  
have to send the whole lot to all of them (thereby sending more than  
you would have done before) or end up sending different 'packs' for  
different pages and then you will end up sending the same js twice to  
some users.

<SNIP>
>   6. Removes the default 'ver' query parameter which WordPress adds to
>   every script src if no version argument is supplied on
>   wp_enqueue/register_script: this is important for Web-wide caching  
> of
>   scripts loaded from ajax.googleapis.com, for example. When  
> registering
>   new scripts, pass the filemtime in as the version so that whenever  
> a file
>   changes, the concatenated script will be regenerated.

This issue of ver being included even when not supplied will not be  
avoidable using the core in 3.0 following on from the fix of this  
ticket - http://core.trac.wordpress.org/ticket/11315

> This plugin also relies on server configuration in that a far-future  
> expires
> header must be set, or otherwise the plugin will abort concatenation.
> (However, the optimizescripts_expires filter mentioned above is a  
> workaround
> for this.)
>
> I'm eager to hear what you all think about this approach and if  
> would be
> good to include in WordPress core so that it can be fast by default  
> in how
> it serves scripts.

I don't think this is something that we should be including in the  
core in the short term.

I do think that there is the potential for a canonical/core plugin  
which fulfils this use-case for those people that need it .

It would be great for all the different plugin developers in this  
space to combine there skills and ideas and come up with one plugin  
which works in all the different environments WordPress does.

-- 
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5



More information about the wp-hackers mailing list