Going to Performance School: YSlow, WordPress, and ComicPress

I’d known about Yahoo!’s best practices for high-performance Web sites for a while, but never look too deeply into it, ’cause I’m lazy. Then I learned about the YSlow plugin for Firebug, which analyzes your Websites according to their major recommendations and rolls up the results into…handy little grades. And, to be honest, a fair number of their recommendations don’t apply to the majority of sites on the Internet. Unless you’re Yahoo!

But that doesn’t mean you can’t take some of their very well-researched advice and speed up your ComicPress-driven Website. Note that this list doesn’t include the one obvious optimization for a graphics-heavy site, which is save out the proper image format for your comics. Either use a reasonable level of JPEG compression or use PNG files and crush the heck out of them with pngcrush or OptiPNG. C’mon, you should know this one by now.

Some of these suggestions apply to any site running WordPress. Some of them require some deeper-level access to your Apache configuration than some hosts give. And some of them require changes to core ComicPress functions, which will make upgrading difficult. If you’re using IIS, you’ll have to find the equip You have been warned.

Also note that I am no expert on HTTP, browser-related network issues, or anything like that. I’m just a little ole’ Web developer who draws funny pictures, distilling down what I’ve read to youall. So if I’m way off-base, please let me know in the comments.

Let’s go through some of Yahoo!’s recommendations and see what measures make sense for our ComicPress sites…

Minify JS

Minification is the process of removing unneeded code from JavaScript and CSS files. This can trim a few KB from your download times. If you can combine all those minified files together, you can also reduce the number of HTTP requests as well. Minification is best done right before you make your Website live, and unless you have some automated tool for doing this, I find that it’s a pretty inconvenient process.

Luckily, Leon Chevalier did all the heavy lifting and has created a WordPress plugin for his PHP Speedy library. It’s quite easy to set up — if you’ve worked with WP Super Cache, the setup for PHP Speedy will be similar. There are a number of others parts of the minification process that you can control, and you can read more about those settings on the relevant Yahoo! pages (far future Expires headers being the biggest win). As long as the process doesn’t screw up your JavaScript code, this is a very easy addition to your site and gets you some pretty big benefits for very little work.

Gzip components

For those of you who have a host that allows you to enable mod_deflate…DO IT. This particular rule is not talking about WordPress’s built-in Gzip compression, or PHP’s automatic Gzip output of HTML content (though they certainly help if that’s all you can do) — rather, they want you to enable site-wide compression of any text-based file, including HTML, XML, CSS, JavaScript, JSON. I don’t know how most normal Webhosts like DreamHost, GoDaddy, or the others handle enabling this (and if you do, please enlighten me), but on my Linode (affiliate link), which is running Apache 2, I use a directive like the following to automatically compress almost any text-based content, provided the browser on the other end can handle it:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript application/json text/javascript
</IfModule>

(a lot of the initial code for these changes came from the AskApache site. I tweaked their original settings ever so slightly.)

If you can enable deflate support, it’s another small change that will bring about huge bandwidth savings. Note that YSlow is very brutal when it comes to this recommendation — if, for example, a remote site is delivering JavaScript, like, say, Project Wonderful, and they aren’t Gzipping or minifying the JavaScript on their end, YSlow will lower your grade very quickly (but rememeber, these grades are misleading anyway, so don’t fret! ). [and a request for Project Wonderful: Gzip/minify your ad serving script! Webmasters will thank you! ;)]

Add an Expires Header

I’m still on the fence about this one. In short: Delivering a piece of content with an Expires header means that your browser won’t ping the server with an HTTP request until the date of the Expires header has passed (in theory). Yahoo! recommends that you have an Expires header that is at least two days in the future from the first access of the content. But that long period gives me a not-so-warm and fuzzy feeling. For instance, just this Monday I had an issue on Dawn’s Dictionary Drama that required me to rework a bunch of posts and files, and if that Expires header was longer than an hour or so, my site would have been quite messed up for a lot of viewers for, potentially, days (OK, it would have only affected the five regular readers of that comic. Don’t rub it in.)

I keep my Expires (Cache-Control: max-age, really) time pretty low, no more so than an hour. YSlow complains, but oh well. If your host supports it, here’s how to set it up so that you can reduce some of the HTTP traffic to your site:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 hour"
</IfModule>

Configure ETags

ETags are a different way of handling cache control. The skinny: each unique file on your filesystem has all sorts of metadata attached to it (filename, last modification date, physical location on the drive). An ETag is constructed from those bits. When a browser downloads a file with an ETag, the ETag is stored wtih the file. Modify any of those bits (say, by editing the file) and the ETag changes. When you revisit the site, the ETag your browser has is checked against the ETag on the site. If they’re different, the file is re-downloaded.

YSlow’s ETag complaint comes down to how default Apache ETags are constructed. The default tag has the file system location (inode) in the ETag. If you set up a huge cluster of Apache machines, and put the same file on all those machines, the ETags will be different, since each individual machine will put that file on different inodes. If you’re running a massive cluster of machines to deliver search results, stock quotes, and “answers,” this is a problem. If you’re on a single machine, serving up your funny little Webcomic, it’s not a big deal. Don’t worry about this one and worry about implementing Expires headers instead.

Use A CDN/Reduce DNS lookups

Here’s two suggestions that seem to run counter to each other. I can tell you right now that if you’re running PW ads, have a Frumph.net (promotional link) rank image, and also pull in social networkings icon from, say, Delicious or StumbleUpon, you’ve already broken YSlow’s 4 DNS lookup rule. In a nutshell: a Domain Name Service lookup happens when you have a domain name (say, claritycomic.com) and you need to turn that into a number (64.22.103.36) that your TCP/IP networking stack understands. This initial lookup can take a few milliseconds, but once it’s done, that looked-up number is cached in your browser or TCP/IP stack. Reducing DNS Lookups is akin to making sure your tires are properly inflated in order to get good gas mileage — it helps, but don’t expect to make your site’s performance hit Ludicrous Speed.

Now, why is this counter to Use a CDN? Because Use a CDN (content delivery network) really means Split Your Static Content Up Into Different Subdomains To Trick A Your Browser Into Downloading More Content At Once (and for a site of your size, it does not mean Sign Up For Akamai Or Mirror Image). You’ll be adding more domains to your page that need to be looked up, which could push you over the 4 domain limit imposed by Reduce DNS Lookups.

Most browsers, by default, only open two parallel connections to a server to download content (it’s in the HTTP 1.1 spec). Hacks like FasterFox can make a browser open up more connections, but other browsers don’t have that advantage, so you might as well try this change — by putting some of your content on a second domain name (even if it’s just a subdomain), the browser will open up twice as many parallel connections (4 instead of 2) to your server to download content. Note that this change not only requires modifying your Apache configuration, but also modifying your ComicPress functions.php file.

If you can set up subdomains for your site, and point that generated subdomain at any folder that your account owns, set up a “static.mysite.com” domain and point it to the root of your current site so that:

http://www.mysite.com/

and

http://static.mysite.com/

deliver the same content (WordPress, images, etc.). If you’re super-paranoid, this is the point where you lock down Apache so that you’re only delivering “static” files on the static address.

Now, in functions.php, let’s kill two birds with one stone. Above the first function in the file, let’s define a new constant:

define("CP_SOURCE_URL", 'http://static.mysite.com'); // note the lack of trailing slash

and then find every instance of:

get_settings('siteurl')

and replace it with:

CP_SOURCE_URL

Save your changes and make sure your comic still shows up on your site. If you’ve got Firebug, or if you want to peek at the source, make sure the <img /> tag for the comic is pulling the image from static.mysite.com. Congratulations, you just tricked Web browsers into downloading more content than they normally do! Now, if you’re including any stylesheets, JavaScript files, or image files in your theme, you can point them at the static URL, too. This will be a bit more complex to do, so experiment carefully.

Dawn’s Dictionary Drama is already set up this way. A Moment of Clarity will have this setup soon, too.

Make Fewer HTTP Requests

Here’s one that I have yet to do, simply because it is a bit more involved, and it’s a part of the process I wish I could automate more. Make Fewer HTTP Requests means Download Less Objects, and, if you’re using PHP Speedy, you’ve already done some of that. The other primary way to reduce the number of HTTP requests is with CSS sprites. CSS background images can easily balloon up the number of HTTP requests that need to be made to the server, and each one brings about additional overhead. By combining all of those images into a single background image, and using background-position on elements to only use a small part of the combined background image, you can severly reduce the number of HTTP requests made to the server, at the cost of additional complexity in your CSS file.

I’ll admit this is an area I don’t have a lot of experience with, so if anyone wants to recommend the best way to handle this process, especially in an automated fashion through WordPress, I’m all ears. I do know there’s this CSS Sprite Generator tool which looks pretty cool, but I haven’t tried it yet.

So there you have it. A hodge-podge of techniques for making your comic site even more responsive, and with very little work on your end. Your visitors, and the Internet, will thank you.

Stumble it! :: Bookmark this on Delicious