To defeat rules #3: Add an Expires or Cache-Control Header, #4 GZip Components, and #13 Configure ETags, we need the following .htaccess swank (thanks to Matt Robertson for noticing that the rules I had here were not compressing CSS or JS):

# MOD_DEFLATE COMPRESSION
SetOutputFilter DEFLATE

# 1-WEEK EXPIRES HEADER
ExpiresActive On
ExpiresDefault A0
ExpiresDefault A604800
Header append Cache-Control "public"

# PUT YOUR WP SUPER CACHE RULES HERE

# KILL THEM ETAGS
FileETag none

# YOUR WORDPRESS PRETTY PERMALINK RULES GO HERE

GZip Compression

In the above, I use mod_deflate compression because I'm hosted on MediaTemple, which doesn't offer gzip compression. The rules turn on mod_deflate for my CSS and Javascript because I'm also using WP Super Cache, which handles compression for everything else. In tandem with WP Super Cache, everything on my site is gzipped, and therefore YSlow gives me an A for rule #4.

If you don't have the mod_deflate module on your shared space, you likely have mod_gzip enabled, so use that:

# IF YOU CAN'T USE MOD_DEFLATE...
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$ mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*

This won't work on a variety of ancient browsers (pre-IE6, Opera 5, and Netscape, for example), but of course, who the hell cares.

Expires Headers

The idea here is that if you tell the browser the lifespan of your assets, the browser will keep them in its cache longer, which means your readers will be able to browse faster, from page to page, after they've downloaded your assets after the initial page load. Sounds a bit sketchy at first, but then I remembered that most people never CTRL+click Refresh or bother clearing their cache, so we can rely on their laziness.

My example above expires just about any kind of asset 1 week after it's downloaded, but keep in mind that you have a lot of options when it comes to assigning these lifespans. It really depends on how often you change your content on your end.

Assigning Dynamic Images Cache Control Headers in FLIR

After much Interweb soul-searching, I decided that FLIR, the Facelift Image Replacement Method, is the best image replacement method out there (for my purposes, at least). I used sIFR 3 for a long time to render fancy fonts on my site, but every day when I looked at myself in the mirror, I was ashamed, among other things, for having to resort to Flash for such a trivial task. I intend to write an article about image replacement methods and the reason why I ultimately decided upon FLIR, so more on this later, but the point of my bringing this up is that the Facelift Image Replacement WordPress Plugin (which forks off the real FLIR) generates dynamic images for fonts, but doesn't assign them cache-control headers.

Hours of Googling landed me on this page. Here the author provides a solution to the problem. He writes:

New user visits a brand new uncached image, it is generated. They refresh the page, another request is probably made and a 304 not modified is returned. You're right, this is unnecessary.

I think by adding a cache-control to the output_file function the images would then get cached by the browser without causing an extra call to verify that it hasn't been modified. This should stop a lot of unnecessary trips to the server.

The corresponding file in the Facelift plugin is inc-flir.php, located in the plugin's /facelift/ folder. Scroll down to line 395, and add the following:

/* add this line */
header('Cache-Control: max-age=1209600, public, must-revalidate');

/* before the following lines */
header('Last-Modified: '.gmdate('D, d M Y H:i:s GMT', $ts));
header('ETag: "'.md5($ts).'"');

Adjust the expiration time to your liking. Now YSlow won't complain that the dynamic images generated by FLIR have no cache-control headers.

ETags

Last but not least (well yes, maybe least), the mystical "entity tags." These little things creep me out like Leeuwenhoek's animalcules or FMA's homunculi. To paraphrase Yahoo, Etags are just doodads that servers and browsers use to check if the assets in the browser cache match up with original assets from the server. In the performance rules, Yahoo gripes about ETags because they don't quite do what they're supposed to do if your site pulls its assets from multiple servers. Of course, the vast majority of websites aren't doing this because the vast majority of website owners are cheapskates. Nevertheless, YSlow will give us a big fat F if we try to actually configure ETags "correctly." Since there's little space left in our brains to debate such nonsense, Yahoo instructs us to simply turn the little entities off. And frankly, my dear, I don't give a damn.

Now, would-be ultra-"l33t" programmers might enjoy using a command line, but I sure don't. It's a waste of the time Darwinian evolution spent on developing my eyeballs. Instead, swing on by to this cool guy's website, http://refresh-sf.com/yui/, where you can just copy paste your CSS or JS into a text field and get it minified/obfuscated without fiddling with Stone Age command prompts.

What happens when we have to make changes to our files after they've been minified/obfuscated? Since I don't use a fancy development environment to handle my files, I just minify/obfuscate the files that are up on the server and leave my local files alone. If I need to make a quick CSS change, I make them locally and just find/replace the same lines on the server. Janky? Yes. Not ideal? Sure. But it works.

* Keep one thing in mind when you minify/obfuscate: comments get stripped out entirely, and usually the software license or developer credit for freeware is contained in those comments. After some meditation on this matter, I decided that it's silly to keep the comments in after minification; that would be doing it half-assed and ultimately it defeats the purpose. As a compromise, we should have a page in our website that credits the creator of source code we borrow from the open source community. This provides even more visibility for our open source colleagues while allowing us to fully minify our files.