First thing's first:

Download YSlow for Firebug if you haven't already, then skim over Yahoo!'s article about the thirteen best practices for speeding up your website:

1. Minimize HTTP Requests - (Don't make me download a lot of crap.)
2. Use a Content Delivery Network (Have someone else serve your shit.)
3. Add an Expires or Cache-Control Header (Stale bread is best for french toast. Really.)
4. GZip Components (Zip it up!)
5. Put Stylesheets at the Top (I need to see your site before I click on stuff, dumbass.)
6. Put Scripts at the Bottom (See above.)
7. Avoid CSS Expressions (Who uses them anyway?)
8. Make Javascript and CSS External (Duh.)
9. Reduce DNS Lookups (Don't be a social media slut.)
10. Minify Javascript and CSS (Nobody wants to see your whitespace.)
11. Avoid Redirects (I came to your site, not theirs.)
12. Remove Duplicate Scripts (Duh.)
13. Configure ETags (Yeah, I didn't know what these were either.)

I also recommend setting up WP Super Cache after all is said and done. So here we go:

• The Unavoidables: Don't Make Me Download a Lot of Crap; or, Sometimes You Just Deserve an F From YSlow, You Shameless Self-Promoter
• Three Sexy Performance Rules for .htaccess on WordPress: Configure ETags, Gzip Compression, and Expires Headers
• Nobody Wants to See Your Whitespace: Minify CSS and Javascript using Yahoo!’s UI Compressor

* Full disclosure: Where do I stand? My front page gets a big fat B (88%) for making you download a lot of crap:

YSlow Score: DQuinn.net Home Page

YSlow gleefully reports that 32 CSS background images is downright sinful.

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.