• Use a browser development plug-in, like Firebug and YSlow
• Learn JavaScript

This author also mentions using a reset stylesheet, something I wasn’t familiar with but is also mentioned in…

…the 10 Dirty Little Web Development Tricks article at Yongfook. That author also recommends using a versioning system like SVN (to control the different versions of files as you work with them), which I feel makes more sense if you’re working on something with a team. Along with recommendations to learn the jQuery JavaScript framework and the Zend PHP framework, the author also suggests you take a break, perhaps the best piece of debugging advice that I’ve ever also given (I always include that in my books). There’s also some best-practices there related to using frameworks and MVC approaches to sites.

New to me, and a slightly negative reflection on my site, was entity tags (ETags). An ETag is a unique identifier for a resource. A browser (and other software) can check a resource’s ETag to know whether or not to download the resource, somewhat similar to how expiration headers are used. An ETag can be any value that represents the resource and changes when the resource changes. Commonly the server might use the file’s modification time for this value, or a hash representation of the file as a whole (e.g., run the file’s contents through an MD5 function). My server was providing ETags for all but the main PHP page. This makes sense, because PHP pages aren’t like static HTML pages: my main PHP page is updated whenever the database it uses for its content is updated.

One fix would be to have PHP send an ETag header:

header("ETag: \"representative value\"");

As already written, the representative value could be any of the following:

• The modification time of the last database record used by the page
• An MD5 representation of the entire page, including the database-driven content
• An MD5 representation of just the most recent database record that’s reflected on the page.

And the answer I came up with was…just to ignore ETags on this PHP page. Coming up with any of those values would require a decent rewrite of the entire page, something I just don’t feel like doing right now. And, in my defense, my score turned out pretty well after I addressed the JavaScript and CSS compression issue…

Another reason I lost points was because two of the files being sent (the JavaScript and the CSS) weren’t being compressed. Most of my site uses PHP, which uses the zlib library to compress data sent to the browser. So PHP on the server compacts the HTML, it gets sent to the browser in compressed format, then the browser decompresses it and reads it. That’s great and generally recommended, but the JavaScript and CSS pages aren’t being handled by PHP. One solution is to use Apache’s mod_gzip or mod_deflate module to compress CSS and JavaScript files. To do that, add this code to an .htaccess or .conf file:

<IfModule mod_deflate.c>
<FilesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

That code basically says if mod_deflate is loaded, any file that ends with .js or .css should be ouptut using the deflate filter.

After I took all these steps, I got my YSlow grade up to a 98! I’m pretty pleased with that result. Also, in more concrete terms, if a user accesses my home page for the first time, they perform 4 HTTP requests and download just over 21KB of data. Subsequent requests of that same page require only 1 HTTP request and 3KB of data to be downloaded. That should make a big difference.

To wrap up this thread, I’ll mention two things. First, the YSlow plug-in and report is a very useful tool, but it’s not the only test or indicator of a site’s performance. I do think it’s a great place to start, though. Second, in researching some of these fixes, I came across several other sites where people did the same thing I did (tested their site using YSlow, then tried to address the problems). If you’re interested in this process, you may want to search online to read some of those other articles.

(As a post-script, I will add that one can improve the ETag score by disabling ETags in Apache, strange as this may seem. By doing so, it forces browsers to rely upon the caching headers. So if you can’t or don’t want to get ETags to work, turn them off and they won’t cause a problem.)

As always, thanks for reading and let me know if you have any questions.

I do have two or three Web sites to do in 2009, but even a fairly complex site requires much less of me than a full-on book, so I don’t consider those to be major hurdles. Plus, I need to keep my skills up and use new sites as an opportunity to try and learn new things. So how will I be spending most of my so-called sabbatical?

Besides exercising and reading more, doing some stuff about the house, and playing some Nintendo Wii (a present to myself), there are lots of work-related tasks ahead of me. I buy quite a lot of computer books (I’m a book person, in many ways) but I don’t always read them as thoroughly as I would like. This is a great irony, as I write books that I hope/expect others to read in order and completely. Anyway, so I’ve got about three dozen books that I’ve purchased over the past few years, mostly on advanced programming concepts, Ruby, Ajax, and PHP, that I’ll be going through, using this blog as a place to keep notes on the most interesting things I learn. Or, more likely, things I once learned but since forgot and was happily reminded of.

Second, there are some new technologies that I want to either learn from scratch or improve my knowledge of. In the latter category, I plan on more fully mastering the Zend and Ruby on Rails frameworks (in PHP and Ruby, respectively). Both are talked about a lot and I think the only way I’ll come up with an opinion of them with which I’m comfortable is if I give them both a fair shake. I’ll be posting my continued results in this blog. Of the new topics I want to investigate, Flex is probably foremost. (As I’m writing this, I’m on my way to the Adobe MAX 2008 conference in San Francisco, where I’ll start the Flex learning process.)

Finally, I have been promising and do intend to create an online guide to JavaScript. I get frequent requests for writings on this subject and as my primary publisher (Peachpit Press) already has a JavaScript book out, it’s unlikely I’ll ever write a formal one. Anyway, I’ve created a Wiki on my site for this purpose and started roughing in the pages. Once I have a decent amount of content there, I’ll make it live.

If you have any questions about any of this, or if there’s something you’d like me to do or look into during my sabbatical, let me know and I’ll see if I can oblige your request.