Our greatest weapon against the admonitions of YSlow is .htaccess, that innocuous text file that has the capacity to blow up your website.
For those of us cheapskates on shared servers, our greatest weapon against the admonitions of YSlow is .htaccess, that innocuous text file that has the capacity to blow up your website if you mistreat it.
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
# 1-WEEK EXPIRES HEADER
Header append Cache-Control "public"
# PUT YOUR WP SUPER CACHE RULES HERE
# KILL THEM ETAGS
# YOUR WORDPRESS PRETTY PERMALINK RULES GO HERE
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_item_include file .(html?|txt|css|js|php|pl)$ mod_gzip_item_include handler ^cgi-script$
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.
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));
Adjust the expiration time to your liking. Now YSlow won’t complain that the dynamic images generated by FLIR have no cache-control headers.
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.