Ok, so I admit I’m a little obsessed with performance, but who wouldn’t be? If you had a choice between a heavy slow site that will annoy your users or a lightweight snappy site your users will come back to over and over again, what would you choose? Thats what I thought. Ok so lets assume you have optimized all your queries, saved all your images in the correct format, have fast PHP code and CSS so clean you can eat off it. You probably have a pretty fast site. But it could be faster! Let me show you how.

Note: This only works with Apache 2.0+ and the compression will only work if your apache configuration has “mod_deflate” turned on.

To help visualize this speed up, I’m using the plugin YSlow for firefox’s Firebug. If your not using Firefox already for development, shame on you. Lets take a look at the site as it is now.

As you see, we get a nice fat score of F. This isn’t like getting an F on your math test though, this plugin is a VERY hard grader. However, it won’t take much to improve this score. As we see in the top graph, even with our browser cache, we’re still pulling down 52.2k and the real killer 36 requests. We look at our report card and see why we failed. I’m only gonig to talk about the things we are going to fix. “Add Expires Header” is first. Basically when we serve up a file we can give it an expires time. That way the browser will KNOW that the file it has in its cache is still good until that date comes. We can set that however long in the future we want. The next is “GZip Components”. This is a type of compression that can be applied to most code files (js, css, html, php) that get served up as they are text based and have lots of wasted space. This means that the browser has less to download from your server. As you see I’ve already put my CSS on top and JS on the bottom which is always good coding practices. The last thing is “Configure ETags”. Its hard to explain how these things work, but basically its a time/server stamp on every file so the browser can ask the server if it has a new file. However, with our expire times already set, we don’t need/want the browser to waste its energy checking these. The problem with ETags are that even if your browser has a perfectly good cached version of the file, it is still going to bug the server for a new version. This is a request and is bad.

There is a snippet to help all of these issues in one swoop. An .htaccess genius Vinny I work with came up with this clever script you can simply drop in your root .htaccess file and it will make your score MUCH better. Here it is:

<FilesMatch “\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$”>
Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault “access plus 4 day”
</FilesMatch>

<FilesMatch “\.(html|htm|php|js|css)$”>
SetOutputFilter DEFLATE
</FilesMatch>

After dropping that guy in there, you’ll get a score that looks like this:

Look at That!  Only 1 request and the rest was cached.  Thats better savings than if you woke up at 4am on Black Friday to go to Best Buy.  The only issue is that if you updated your CSS file and uploaded it, some people would have to wait 4 days to get the new one.  However, there are cache busting techniques I’m working on automating that I’ll share with you soon.