[intlink id=”128″ type=”post”]In a previous post[/intlink], I talked about using Yahoo!’s YSlow Firefox plug-in to analyze and improve your Web site’s speed. In that post I mentioned that my site—www.larryullman.com—fared pretty well (an 86 out of 100) but there were a couple of things that I hadn’t even heard of before. Well, I started making some tweaks, and here’s the result so far, including discussion of CDNs, which were new to me.
First up, it turns out that CDNs are Content Delivery Networks. The premise is that instead of storing all your site’s content on one server, you should store it on multiple servers around the country or world. Then users will be able to download specific files from your site from a server close to them (this all happens behind the scenes; the end user isn’t aware of it). Now, my Web site is just on one server and doesn’t merit using a CDN, so this didn’t really apply to me. I was, however, able to fake a CDN by following these steps.
The second thing I did, which meant an actual change on the site (as opposed to the CDN issue) is minify my JavaScript. I used Yahoo!’s YUI Compressor to take my site’s primary JavaScript file and reduce it from about 16KB to 12KB. That’s a 25% reduction, which is significant enough. I did not thoroughly test other minimizers, which may do better or worse at this task. From what I’ve read, though, the YUI Compressor does a good job.
Those two changes bumped my rating up to a 90. I’ll also point out here, that one strong factor in the “grade” is the number of HTTP requests that need to be made. In other words, how many times does the browser need to go to the server to get something. My home page makes only four requests—the HTML page, one JavaScript file, one CSS file, and one image file, so it ranks really well in this category. If your site has a lot of HTTP requests, like if it uses a lot of images, you may want to consider using combined files and CSS Sprites to cut down on that.
Another downgrade came from a lack of Expires headers on the JavaScript resource, the CSS file, and the image used on the tested page. One fix for the two text files would be to make them PHP pages, then use PHP to send the right headers. Another option was to configure Apache by adding this code to an .htaccess file (or better yet, a .conf file):
#Far Future Expires Header
<FilesMatch "\.(gif|png|jpg|js|css|swf)$">
ExpiresActive On
ExpiresDefault "access plus 1 years"
</FilesMatch>
I came across this specific tip at this article, in which that author went through the same process I’m going through now. That writer, and the original Yahoo! article, both discuss using an ExpiresDefault value of “access plus 10 years”, but I think one year is sufficient (and, yes, you still need to use the plural of “years”). The problem with setting a high ExpiresDefault value like this is that the caching mechanisms, like the browsers, will not try to retrieve that resource again for that time period (unless the cache is cleared). So if you change the CSS or JavaScript file, you’ll need to rename it in order to have its changes reflected in the browser. No doubt this will trip me up the next time I make some minor edits to the CSS. The previously cited article has additional code for creating an automatic versioning system that’s a good work around, if you want to go through that effort.
UPDATE: I was just reading an article at Sitepoint about caching and it mentioned a tip for forcing a browser to re-download a resource. What they suggested was adding a pseudo-version as a GET variable in the CSS or JavaScript request:
<link rel="stylesheet" type="text/css" href="pagename.css?v=1.1" />
At this point, my YSlow score is up to a 95 (whohoo!), which is excellent, but I can still take a look at my ETags and compressing my JavaScript and CSS files. I’ll do that in another post.
