It’s probably pretty obvious that resource minification is a good thing. The bandwidth savings this affords you are probably negligible, but the fact that your site has fewer objects to load means faster page load times, and fewer requests sent to your server.
Ideally, you’ll have one file for all of your javascript source, and one more for all of your stylesheets. There are some pretty nifty WordPress plugins that do all of the work for you. This is great. Whenever you update your javascript or stylesheets, these plugins will generate a fresh minified file for you automatically. How lovely.
One has to be careful, though. Gathering up all of your source, minifying it, and throwing it all into a single file is a slightly costly operation. It’s a good thing, then, that all of the plugins I mentioned earlier provide some sort of caching mechanism. Some are a little less thoughtful of performance, however. Consider, for example, Better WordPress Minify. Here’s what the link to my minified javascript file looked like:
http://blog.christophermullins.net/wp-content/plugins/bwp-minify/min/?f=wp-includes/js/jquery/jquery.js,wp-content/plugins/crayon-syntax-highlighter/js/util.js,wp-content/plugins/crayon-syntax-highlighter/js/crayon.js,wp-content/plugins/crayon-syntax-highlighter/js/jquery.popup.js,wp-content/plugins/crayon-syntax-highlighter/js/fancybox/jquery.fancybox.pack.js,wp-content/plugins/crayon-syntax-highlighter/js/crayon_admin.js,wp-includes/js/thickbox/thickbox.js,wp-content/plugins/crayon-syntax-highlighter/util/tag-editor/crayon_te.js
This is clearly getting passed to PHP every time someone requests the page. Why is that bad? Because PHP is a resource hog. Serving a static file is almost always cheaper! This is especially true when PHP is just going to read a cached file from the disk anyway. As far as I can tell, that’s exactly what this plugin does. I can’t seem to find any way to change the caching mechanism without editing the source. Here’s how it serves cached files:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public function fetch($id) { if ($this->_locking) { $fp = fopen($this->_path . '/' . $id, 'rb'); flock($fp, LOCK_SH); $ret = stream_get_contents($fp); flock($fp, LOCK_UN); fclose($fp); return $ret; } else { return file_get_contents($this->_path . '/' . $id); } } |
In contrast, here’s what the minified javascript link looks like under W3 Total Cache’s minify:
http://blog.christophermullins.net/wp-content/w3tc/min/92903ecb.6593de.js
This looks much nicer! This is, in fact, a static file. We could even serve it from a more lightweight web server, or push it to a CDN. W3TC supports doing both of these things. Here’s the magic: if the file exists, it’ll be served normally. If it hasn’t been generated, the request will eventually hit this rewrite rule:
rewrite ^/wp-content/w3tc/min/(.+\.(css|js))$ /wp-content/w3tc/min/index.php?file=$1 last;
This forwards the request to W3TC’s minify handler, which generates and caches the minified resource. From that point forward, it’ll be served as a static file. Nice!
Incidentally, W3TC’s page cache does exactly the same thing. When configured properly, this plugin makes it pretty easy to withstand pretty heavy traffic spikes.
You might not notice the difference in performance when your server is under a light load, but trust me. If you let PHP handle the caching, you’ll get a visit from the 502 Bad Gateway fairy in no time.
Of course, this all assumes you’re on a single host and have no interest in stuff like memcached.