Article
Practical Web Design - Speed Up Your Site
Omitting Optional Closing Tags
Okay, here's one that saves some bytes but violates XHTML standards, which mandate that all tags must be closed and attributes must be fully qualified. If this doesn't concern you, then these tags don't have to be closed: <P>, <LI>, <OPTION>, and even <BODY> and <HTML>. You can also omit the closing tags for the <TR> and <TD> tags, but Netscape 3 won't render tables properly without these closing tags.
This is a tradeoff between page size and rendering speed: HTML with all closing tags renders slightly faster, but omitting the closing tags reduces page size and still allows the code to validate. It's a choice you'll have to consider.
Comments
Comments are rarely necessary for code to display properly. They're usually included to mark particular sections of documents or to give information to the designers for their own use. The more you can get along without comments, or you can abbreviate and compress the commentary, the tighter and more efficient your code will run.
Minimizing the <HEAD> section
In your <HEAD> section, META tags, style sheets, and JavaScript take up a great deal of space. The less you're able to get along with, the faster your site loads. Remember, everything in your <HEAD> section must parse before the rest of your page loads.
META tags are often overused. While they are necessary in some instances -- keyword specification for some search engines, defining default scripting, style sheet languages, and character sets, augmenting HTTP headers sent from the server, and so forth, many of them are either redundant or unneeded. In the strictest sense, the only META tags you absolutely need are the KEYWORDS and DESCRIPTION tags. The rest are superfluous or can be handled better by server settings (for more information on using META tags, see my Practical Web Design column, Top 15 META Tag Tricks).
Optimizing Tables
Andy spends an entire chapter on table optimization, and I won't try to sum everything up here. I'll just point out that tables take time for browsers to untangle and parse, and the more you rely on tables for your page design, the longer it takes your visitors to access your site's content. Between untangling the variety of table structures, placing images in the table cells, and running back and forth with dozens of HTTP calls to get everything up and running, it can take far, far too long for a page to load.
Telling the browser as much as you can about the table's structure and complexity, and reducing the complexity of your tables whenever possible, is the way to maximize efficiency. Simplify whenever you can. Use CSS to style tables. Use background colors instead of background images. And if you really want to speed things up, get rid of tables altogether and lay out your page using the various <DIV> elements and CSS2 (Andy gives another chapter's worth of advice on this particular topic).
One thing we can all do is give the browser enough table information to be able to render the table incrementally instead of having to wait for everything to load ahead of time. You can use the COL and COLGROUP elements to tell the browser how many columns you're using and their widths (in pixels, percentages, or relative widths). This lets the browser make one pass at the table instead of two (the first one finds the number of columns) before rendering. If a table doesn't have a fixed width, the browser must receive every byte of data before they can size the table.
You can also group table rows into table head, foot, and body sections using the THEAD, TFOOT, and TBODY elements. Andy says it well: "You can format these groups separately and use them for printing longer, multi-page tables when you want header and/or footer information to print on each page" (p. 69).
A lot of sites (including mine) use one all-encompassing table to lay out most, or all of the page. Often this means that the browser has to download everything within that table before it can display it. A page that sits and sits, seemingly doing nothing, then suddenly displays all at once, is probably laid out this way. Why force your audience to wait like this? Instead, layer your tables. Start your page off with a small, fast-loading table that contains something useful like a search box, a navigation bar, or at the very least a title graphic, to reward the efforts of your visitors, and assure them that your page is, indeed, coming down the pike. An "above-the fold" table lets additional content load just after the first table, giving your visitors something to grapple with while the rest of your page loads. Even if your entire page loads more slowly than before, it's worth it to give your visitors something immediate to work with (and no, ads that pop up first don't count. Visitors didn't come to your site to look at ads).
If you're working strictly with browsers that are CSS2-compliant, you can use the TABLE-LAYOUT property to speed table rendering. This property lets us control the algorithm that browsers use to lay out the table cells, rows, and columns.
Trailing Slashes in URLs
Some people don't think there's any difference between these two URLs:
http://www.mysite.com and http://www.mysite.com/
but there is. The trailing slash tells the browser that the URL points to a directory, and as a result the browser doesn't have to decide whether the URL points to a directory or a file. You can speed up a URL's response time by including the slash behind a directory listing (not a file -- don't do this: http://www.mysite.com/index.html/).
Putting CSS to Work
I'll let you buy the book for the details on this area of optimization, but in brief, using CSS to replace image rollovers and table-based designs is well worth the time and effort it will take you to convert. As more and more users change over to modern browsers such as IE 5+, Netscape 6+, and Mozilla, you'll have fewer issues with users whose browsers refuse to support CSS.