lyncd

Minify for WordPress and WP Super Cache

I’ve integrated Minify and all its bandwidth-saving goodness into WP Super Cache, everyone’s favorite way of sending WordPress pages as super-fast static HTML, thereby saving visitors having to hit up the PHP interpreter (ugh!) or WordPress itself (double ugh!).

What does this mean? Well, it means your HTML (and gzipped HTML) pages can be 5-20% smaller with just a few minutes’ setup. If that sounds good, skip to the install instructions. If you want to hear more blabber first, read on.

What this does, pros and cons

Minify strips unnecessary whitespace and comments to reduce the size of CSS, Javascript and HTML files, most often to shrink and combine multiple CSS and JS files to reduce HTTP connections and save bandwidth, important optimizations for high-performance websites. This is the same longstanding technique that, for instance, Googles uses on its famously simple www.google.com homepage to squeeze out every last byte.

Minify can also use PHP to do on-the-fly compression of CSS/JS (So convenient! But a drag because it touches PHP!) and send HTTP headers to enable aggressive browser-caching of components (Awesome! Especially with an upstream accelerator like Varnish or Squid! But not as useful a technique for HTML, especially with time-sensitive content like on a blog, and where permalinks matter).

HTML only … for now

So what my plugin mod WPSCMinify does, it does only for HTML pages — not for CSS/JS. Why? Because I prefer to pre-Minify these helper files as part of a build process so they’re fast, small and static, instead of being relayed through the big slow PHP interpreter (Minify foresees something like this in current project goal #3). So, if you’re looking for seamless static-served CSS/JS minification with WordPress, sorry. That’s not what my mod does. I suppose I might be persuaded to tackle that in future. :)

If you’re reading this, then hopefully you’re familiar with WP Super Cache. What it does is save complete WordPress pages to the filesystem as both HTML and gzipped HTML, so that the web server can serve them directly and not have to touch PHP or (god forbid) initialize WordPress (authenticated visitors still get dynamic pages).

All my modification does is to run these pages through Minify first, so they wind up a bit smaller. How much smaller? Well, it depends what’s in your pages. In my testing I found the gzipped versions to end up 5-10% smaller, and the plain HTML versions to end up 10-20% smaller. So, we’re not talking miracles here, we’re talking 10%. If your site isn’t under the kind of load where that matters to you then, by all means, adhere to the KISS principle and don’t Minify your HTML.

The tradeoff: file size for CPU

The cost associated here is the CPU used to run Minify through your page the first time it is rendered before it is saved to the filesystem — and Minify is basically just a lot of regex, so this cost isn’t negligible.

Imagine an alternative scenario, with no WP Super Cache: You could implement WordPress+Minify much more simply, in about 3 lines of code — just turn PHP output buffering on at the beginning and end of your WordPress template, and Minify the result. That way all of your pages, even the dynamic ones, would be minified (this is basically what the minify-html plugin does). Sounds great! But it isn’t, because it would be robbing Peter to pay Paul, churning your CPU on every request a lot more than the 10% in bandwidth you’d save.

In my testing, the CPU cost of running Minify on HTML was about 0.05 seconds of execution time on a medium-slow desktop machine running idle, with very little variance (+/- 0.002) due to page size. 1/20th of a second may not sound like much, but that number translated to a busy web server under load (even a powerful one) equals something you don’t want to be doing on every request (render delay due to minification will be 5-10x the transfer time saved). But never fear, it’s perfectly within reason in concert with something like WP Super Cache, where Minify only runs once to generate each static page, and never on dynamic pages.

The whole point is to make things faster for users. We’ve all seen the Yahoo! exceptional performance team’s presentations, with its CEO takeaways that Amazon loses 1% of customers for every 100ms and Google 20% for every 500ms. Must make more faster!

Installation

Updated 8/11/10: My mod is now a plugin (no patches needed!) to WP Super Cache. There’s now a project page with updated info and install instructions. Go there now!

Everything that follows on this page is old and should only be used if you absolutely must run an older version of Super Cache for some reason. These instructions are for version 0.3 of my mod, which is compatible with WP Super Cache 0.9.1. Version 0.2 is compatible with Super Cache 0.9. These versions work, and there are no known issues, but are now unsupported. For more information on older versions, see below.

Requirement: You must be running PHP5. Minify is written in PHP5, and my class is written in PHP5.

I’ve tried to keep hacking of Super Cache to a bare minimum, so nearly all of my modifications are in a separate class I’ve implemented as a singleton. However, there is a patch that must be applied that adds hooks into Super Cache, to perform the minification at the correct time and to insert an “on/off” control onto the Super Cache admin settings screen.

If this talk of patches makes you nervous and you’d rather just download a tarball, here it is: wp-super-cache-with-WPSCMin-0.3.tar.gz. Just untar it into your WordPress plugins directory (move any existing wp-super-cache directory out of the way first), and you’re done. (Follow the standard Super Cache install instructions if it isn’t already installed.)

Otherwise, I’d recommend you follow these instructions instead — my patch should preserve any of your own custom mods.

1. Download WP Super Cache (if you aren’t already running it) and follow its installation instructions.
2. Download Minify. Unzip and move the min/ directory into the main wp-super-cache directory.
3. Download my mod, WPSCMinify v0.3 and untar. Apply the patch wp-super-cache.diff to the wp-super-cache directory and move WPSCMin.php into that directory.
4. Log into WordPress, go to the Settings/WP Super Cache page, scroll down to the HTML Minify section, and enable!

That’s it! Here’s the shortcut version with commands to paste into your shell:

# WP Super Cache
# (Skip and cd to the wp-super-cache directory if already installed)
# Read http://wordpress.org/extend/plugins/wp-super-cache/installation/
cd [your WordPress install]/wp-content/plugins # OK, from here just paste
wget http://downloads.wordpress.org/plugin/wp-super-cache.0.9.1.zip
unzip wp-super-cache.0.9.1.zip && rm wp-super-cache.0.9.1.zip
cd wp-super-cache

# Minify
mkdir tmp && cd tmp
wget http://minify.googlecode.com/files/minify_2.1.2.zip
unzip minify_2.1.2.zip
mv min ../

# WPSCMinify
wget http://lyncd.com/files/WPSCMin-0.3.tar.gz
tar -xzf WPSCMin-0.3.tar.gz
patch -p1 -d ../ < WPSCMin/wp-super-cache.diff
mv WPSCMin/WPSCMin.php ../

# Clean up
cd ..
rm -fr ./tmp

# Now you just need to log into WordPress and enable!

Versions

With a couple of exceptions (see changelog) the only changes from one version to the next are that they patch against newer versions of WP Super Cache -- my code hasn't changed. Since my patch only makes a few surgical edits, you can always just download the latest version and apply these edits manually.

• 0.3 (current) tested against WP Super Cache 0.9.1 and packaged with Minify 2.1.2. Will not patch against older versions of WP Super Cache.
• 0.2 patches WP Super Cache 0.9 only and packaged with Minify 2.1.1.
• 0.1 patches WP Super Cache 0.8.4 (may also patch similar versions, this is untested) and packaged with Minify 2.1.1.

Suggestions, bug reports

Yes, I know it's only like 100 lines of code! Still, I welcome any suggestions and bug reports. Just add a comment here.