Caching WordPress content to appease Google Page Speed

I installed the new Google Page Speed plug-in for Firebug (under Firefox) and played with it a little. I’m impressed. It takes a number of ideas from the similarly awesome YSlow plug-in and goes a few steps further, plus adds a cleaner UI. Of course, I found a couple of really obvious things I could fix.

One of the easiest things is to make sure that your static content is cache-friendly. It’s one of those simple tricks that really does have an impact both on the number of bits you have to serve and on the perceived speed of your pages. Sadly, it gets left out of a lot of CMS/Blog systems (including WordPress). To speed things up, I created an Apache .htaccess file with the following:

<FilesMatch "\.(gif|jpe?g|png|css|js)$">
ExpiresActive On
ExpiresDefault "access plus 2 months"
Header set Cache-Control "max-age=5184000, public"

For my purposes, I put this particular set of directives in wordpress/wp-content/.htaccess which means that all my theme and plug-in resources (including images, JavaScript, and CSS) get an Expires header 2 months into the future. It also includes a matching 2-month Cache-Control “public” header to let caches know that shared object caching is fine. With this, both web caches and the browser cache are far more likely to use the copy of these resources they have laying around.

Your mileage may vary (YMMV), but this is good placement for my particular purposes. It may be safe to put these directives all the way at the top of your document root. As with any caching, be prepared to pay some mild penalty whenever these resources actually do change; you’re ceding precise control over when a new version gets served up in order to gain performance (a trade-off you’ll have to weigh). Granted, there are cache-busting strategies (such as versioned file names) that you can use to get around this, too.

The other thing that impresses me about Page Speed is that it actually provides you with better versions of things you have, no extra software required! If it notices you could have a better-compressed image or min-ified JavaScript file, it’ll tell you how much you could be saving and provide it for you at a single click. Very slick.

Next I have to figure out if DreamHost can help me support gzip’ed content…

Update: Bah! I should have just poked around a little. I found a page regarding turning on more DEFLATE functionality from DreamHost’s Apache 2.2 setup. They already automatically deflate several types, but this doesn’t include CSS or JavaScript. It’s a pretty easy addition to the .haccess file I already have.

# gzip more stuff
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript

Unlike the way I did the Expires headers above, this particular technique uses the content’s MIME type when choosing when to apply the DEFLATE output filter. And just like that, I’ve got smaller content!