[wp-hackers] compression and caching

[William Canino]

Weston,

> I'm eager to hear what you all think about this approach

Here's my feedback:

My sites do not change their scripts and css every day, or even once a
week.  And certainly the js and css do not change in-between every
visitor's two pageloads.  For this reason, I think your plugin's
processing is best as a button inside the blog's admin area -- run by
the site admin when so inclined -- and not hooked into the blog page's
loading process.

Your solution is like running "OPTIMIZE TABLE wp_options" on every page load.

On the other hand, I am pleased that your plugin writes .js files, not
.php files, unlike Leon Chevalier's PHPSpeedy.



And, Weston, constructive suggestion: See
http://codex.wordpress.org/WordPress_Coding_Standards .


2009/12/28 Weston Ruter <westonruter at gmail.com>:
> Hi all, I'm new here. Micah invited me to join in on the discussion.
>
> 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.
>
> I have been developing a plugin called “Optimize Scripts” which does just
> this. As the plugin page states, it:
>
>   1. Respects head and footer groups.
>   2. Minifies code using Google's Closure Compiler.
>   3. Caches the concatenated/minified code and rebuilds it only when one of
>   its source scripts expires or changes. The optimizescripts_expires filter
>   is provided which allows the far-future expires time to be forced.
>   4. Filename for concatenated/minified script is the md5 of all the
>   handles concatenated together (thus if an additional handle is provided, a
>   new concatenated script is generated).
>   5. Provides a filter to limit which scripts get concatenated (i.e. jQuery
>   on ajax.googleapis.com should be left alone); by default, all scripts on
>   local host are concatenated, and remote scripts are left alone.
>   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.
>   7. Script optimization can be delegated to a scheduled cron job so that
>   the server does not periodically respond slowly to visitors.
>
> Read more and see examples on the plugin page:
> http://wordpress.org/extend/plugins/optimize-scripts/
>
> 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.
>
> Weston
>
>
> *William Canino* wrote at *Mon Dec 28 21:22:29 UTC 2009*:
>
>> Let me share with you guys my .htaccess file. I got more gains with
>>
>> this config in my experience than minifying and concatenating on the
>> fly hereby killing the CPU of my shared host.
>>
>> # Far Expires
>> FileETag All
>> ExpiresActive On  # enable expirations
>> ExpiresByType text/javascript "access plus 5 weeks"
>>
>>
>> ExpiresByType application/x-javascript "access plus 5 weeks"
>> ExpiresByType application/javascript "access plus 5 weeks"
>> ExpiresByType text/css "access plus 5 weeks"
>>
>> # Javascript and CSS Gzipping
>>
>>
>> # copied from http://zuble.blogspot.com/2007/02/compressed-js-and-modrewrite.html
>> <FilesMatch "\\.js.gz$">
>>
>>   ForceType text/javascript
>>
>>   Header set Content-Encoding: gzip
>> </FilesMatch>
>> <FilesMatch "\\.js$">
>>   RewriteEngine On
>>   RewriteCond %{HTTP:Accept-Encoding} gzip
>>   RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
>>
>>
>>   RewriteCond %{REQUEST_FILENAME}.gz -f
>>   RewriteRule (.*)\.js$ $1\.js.gz [L]
>>   ForceType text/javascript
>> </FilesMatch>
>> <FilesMatch "\\.css.gz$">
>>   ForceType text/css
>>   Header set Content-Encoding: gzip
>>
>>
>> </FilesMatch>
>> <FilesMatch "\\.css$">
>>   RewriteEngine On
>>   RewriteCond %{HTTP:Accept-Encoding} gzip
>>   RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
>>   RewriteCond %{REQUEST_FILENAME}.gz -f
>>
>>
>>   RewriteRule (.*)\.css$ $1\.css.gz [L]
>>   ForceType text/css
>> </FilesMatch>
>>
>> I then saved a minified+gzipped version of each css and js on the
>> respective directories.
>>
>> Don't joke -- I *have* killed a shared hosting CPU before by
>>
>>
>> dynamically concatenating, minifying and compressing assets.
>>
>>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>