The tutorial goes on to talk about organizing HTML files: CSS at the top and JavaScript at the bottom. I’ve heard this before (about putting JavaScript right before the closing tag) but haven’t gotten around to testing it myself. It makes sense, though, as the browser doesn’t need the JavaScript to render the output for the user to see, and because the JavaScript code itself probably can’t do its thing until the HTML has loaded. If you keep reading, you’ll learn how to use CSS image sprites to minimize the number of images that have to be downloaded by the browser. My Web site has practically no images, so I haven’t used this myself, but it’s something that can dramatically improve the performance of a site.

• The storage engine(s) used
• How columns are defined
• The existence of proper indexes
• How queries are written and executed

MySQL supports many different storage engines, each with its own strengths and weaknesses. Which you choose isn’t just a performance issue, it’s also one of features, like whether you need to support FULLTEXT searches (and therefore MyISAM tables) or transactions (which means InnoDB). Sometimes you can get away with using HEAP tables, which exist only in memory. There’s no permanent storage with HEAP tables, but the performance can’t be beat.

For the column definitions, the first goal is to use the smallest possible size for each column. This will be a limitation in your application, so the column’s size still needs to meet or exceed the largest possible value to be stored, but, generally speaking, the more data you want to possibly store, the more space will be required for all the data stored. You should also avoid allowing NULL values in columns. This is a factor in both good database design and in performance optimization.

The indexes you establish, and how they are used by queries, is a serious subject that requires a book in itself. To start, make sure you read MySQL’s own guide to how MySQL uses indexes. Second, learn to run your queries using EXPLAIN to see what, exactly, MySQL is doing when it executes that query. Also, of course, only select the data your application will actually need. No need to retrieve information that won’t be used. And always go back and double-check that your queries need all the clauses and references they’ve got. I’ve been known to leave legacy conditionals in queries that have no effect whatsoever.

For more on some of these topics, see the MySQL manual, of course (which has a section on optimization), the PlanetMySQL blog, and this article at DatabaseJournal.com. Also, if it applies to you, you can tweak MySQL’s behavior from a hardware/OS perspective. For an introduction to this subject, with respect to Linux, check out this article by Jeremy Zawodny, an expert on MySQL performance tuning.

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.

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.

On the other side of the equation, you can perform benchmarks on the server. Finding, and later improving upon, these measurements will improve the experience for all clients, regardless of download speed, computer, or browser type. This is particular important when using server-side technologies like PHP.

Among the many utilities available to benchmark a Web site is Siege, from Joe Dog Software. One of the nice things about Siege, besides it being free, is that it tests a Web server under duress, something that’s impossible for a single individual to replicate. So you can tell Siege to access your site using X number of simulataneous connections and then see the result. On the downside, you have to compile it on Unix-like systems, including Mac OS X, in order to use it. For more, see the Siege Web site and it’s simple-to-follow manual.

• A “report card” for the page’s performance
• The files and images loaded on that page, including JavaScript and CSS
• Listings of specific strengths and weaknesses of the page

Using the built-in YSlow tools, you can also view: page statistics (total size of all files, number of HTTP requests made, etc.), all of the CSS compiled together, and all of the JavaScript involved. You can even test the JavaScript using JSLint. For more on using YSlow, check out its documentation or this screencast.

In case you’re curious, when I tested my site’s home page, I got a ‘B’ (85), which is a decent start. To improve the performance, I need to add expiration headers, use a CDN, and add ETags. And, to be honest, I didn’t even know what these last two were!

Update: I’ve started fixing some of the issues addressed by YSlow. You can read about that process in this other post.