Practical Web Design - Speed Up Your Site

I guess I’ve always liked things simple: function over form, performance over aesthetics, and the like. When I was a wee lad, my dad and I entered the “Pinewood Derby” — a Cub Scouts-sponsored competition to see who could whittle the fastest race car out of a block of pine about the size of your forearm. On race day, you and your folks (usually including one fiercely competitive father who had done most of the work for you) would bring your carved creation to the race site. You’d put your racer at the top of a slide alongside a number of other kids’ works of racing art, and when the whistle blew, you’d let them go. They would roll, or slide, or falter, down the sloped race track, hopefully to victory, at which point your dad would pump his fist in the sweaty faces of the losers’ dads and you’d try not to look embarrassed.

I decided early on that my racer would be simple, aerodynamic, and functional. No spoilers, doodads, or fancy paint jobs to get in the way — just a few ounces of sleekly carved wood that would glide like the wind. So we carved and we carved (“Gimme that knife, son, you’re going to cut yourself”) and we trimmed and we sanded until we had a silky-smooth, bullet-shaped buzzbomb that was guaranteed to send the other kids stumbling home in tears. It was simple, nothing fancy to impede its way down the track. It probably would have won had we not gummed up the wheels with glue so badly that they barely turned. We didn’t come in last, but that was because one other entrant’s racer sat stubbornly in the starting chute and refused to budge at all.

…which brings me to the subject of today’s column. If Andy King made Pinewood race cars, he’d make them simple, sleek, aerodynamic, and functional — and his wheels would turn properly. Instead, he makes Websites. He also founded and writes for Webreference and JavaScript.com, two sites that any Web designer worth his or her salt should consult on a regular basis. Andy has been working on techniques for optimizing Websites since shortly after the World Wide Web was born. In other words, he knows what he’s talking about.

Recently Andy has published a book, Speed Up Your Site: Web Site Optimization (New Riders Publishing, 2003) that sets out in plain, simple English, how to make your site faster from end to end. I was lucky enough to beg a review copy from New Riders, and after reading the book, I knew I had to share some of Andy’s insights with you. I was doubly fortunate to receive the cooperation of Andy himself; he gave me permission to share some of his book’s content with the SitePoint audience (within copyright restrictions, naturally), and even answered a few questions I asked him about the content and scope of the book. You couldn’t ask for more cooperation.

I’m not even going to attempt to sum up the book, nor am I going to try to cover everything in it. Much of Andy’s work is for the more sophisticated Web creator — i.e. techniques on the optimization of DHTML, JavaScript, and CSS code, optimizing graphics and multimedia presentations, search engine optimization, and so forth. This column is written more for the amateur or non-professional Web designer, so I’ll stick to that in my review. But keep in mind that I’m covering the less esoteric stuff. Andy’s book goes where this column dares not tread!

Until your copy hits your desk, you can take a look at the complementary site, WebSiteOptimization.com. Many of the techniques introduced in the book are explained and expanded here.

Overview and Rationale: Loading Speed

The first section gives us a rationale as to why we should care about optimizing our sites. The reasons are strong and convincing: basically, the more we optimize our sites for quick loading and ease of use, the more we’ll attract and keep visitors. Simple enough.

One statistic used to make the case sums it up quite nicely — if your page hasn’t loaded (at least enough to be used) in 8 seconds or less, the average visitor will bail out and go elsewhere. This is bad enough for the average “hobby” or personal page, or for non-profit sites. But for a commercial site, it’s a critical piece of information that should drive the entire site’s design philosophy.

Ever wonder why Yahoo! is the best-known and most-used search engine/directory on the Web? It isn’t the most comprehensive or even the easiest to use (though it’s certainly user-friendly); it is, however, absolutely reliable as far as load time goes. You click into Yahoo! and it appears every time, without fail, usually within 2-3 seconds. Andy goes into a lot of detail as to why Yahoo loads so quickly, but the thing for us to remember is that it loads quickly and reliably every time. Our sites should load so quickly.

“Users associate slow-loading pages with inferior quality products and services, compromised security, and low credibility. Low user satisfaction can lead to abandoned web sites and shopping carts.” — King, p. 25

Even if you don’t depend on your site to pay the rent, you should think very hard about your page’s load time. For the vast majority of us, the whole reason we put our sites on the Web is for people to use them. You want, or you ought to want, your visitors to have an easy and pleasurable experience on your site. The first and foremost criterion for a good Web experience is fast and easy page loading.

There are, of course, exceptions: “artistic” pages that feature a lot of large, intricate graphics; pages that are heavy on streaming audio and other multimedia features; pages that showcase “cutting-edge” Web design effects; and sites that aren’t strictly designed for public consumption, such as “storage” sites used to house .PDF, PowerPoint, and other files. But even graphics-heavy sites can load quickly, if the designer takes the time and effort to make it happen.

Two of my favorite graphics sites, Ryan Bliss’s Digital Blasphemy and my pal Robby’s Low Budget Designs, both have home pages that load (for me) in under 5-6 seconds. Once you’re there, you know that clicking on the big graphics will take some time, and that’s okay. You got there without undue delay.

If your site just has to take more time to load, there are things you can do to keep your more impatient visitors interested. It’s been demonstrated that your page can retain visitors with a load time of up to 20-30 seconds, if you give them some viable content to work with in a few seconds. Some text to read, an introductory graphic or two, or at the very least, some sort of linear or percent-done progress indicator will help to keep their attention and minimize their frustration at your page’s failure to appear immediately.

It’s also a good idea for your pages to remain consistent in their load times. If your home page loads within a few seconds, so should the rest of the pages, unless there’s a clear and overriding reason why they should not. Getting your home page loaded is the first step towards keeping a visitor on your page, but the joy of a quick-loading home page will fade fast if every other page loads slowly. Don’t tweak your home page and let the rest of your content slide; if you’re going to optimize, do it throughout your site.

“The key attribute [for an optimized site with good “flow”] is that it should be very user-friendly and transparent at first, but one should immediately be able to find complexity in it, so as to find quickly the right level of opportunities for ‘action’ that match one’s skills. These ‘challenges’ include the visual aspect as well as the content.” — Mihaly Csikszentmihalyi, quoted by King, p. 34

Several elements contribute to the open, easy “flow” of your Website. Speed of loading is the first element, but not the only one. Ease of navigation is key to having your site work well; this includes providing “signposts — such as site maps, breadcrumb trails, and ‘you are here’ landmarks” (p. 36) to help your visitors move easily and intuitively about your site. Feedback that is fast and clear of purpose is another essential of good site flow: clear internal and external links, navigational tools, and displays of performance variables such as progress level meters, downloadable file size displays, and such.

Your page should be optimized for the skill and knowledge level of your users: offering an “adaptable/adjustable interface that gives users control over their environment’s complexity that is appropriate to their skill level” (p. 36) is a worthwhile inclusion. Simplicity of layout and features is worth more than showing off your cutting-edge coding skills. Remember, the idea is for your visitor to hit your site running, surf through as effortlessly and enjoyably as possible, and leave with the desire to return soon.

Andy recommends SpaceAgent, a $99 program that optimizes graphics and text in Websites for optimal efficiency, as a good first step towards maximum optimization. Naturally, a program like this can’t do the entire job, but it’s a good way to get started.

Rolling Up Your Sleeves: Optimizing Your Code

Here’s where we get into the nitty-gritty of optimizing your site for maximum efficiency. Andy gives a lot of specific information about tweaking and pruning your HTML; I’ll cover some of the highlights.

Minimizing HTTP Requests

I asked Andy the following question: “Which techniques would you specifically recommend to amateur and/or non-commercial Web designers? What about Web designers who don’t work with CSS very much (either by choice or by a lack of understanding of how to use it)?” He replied, “Minimize HTTP requests by reducing the number of objects in your page, and combine adjacent graphics. That is probably the most important technique.”

Every time you include an object — a graphic, a Java applet, an external style sheet, a chunk of JavaScript — the page must “call” the server to have the object delivered. Ideally, your optimized Web page will have as few server calls as possible. Web guru Jakob Nielsen, one of Andy’s bigger influences, estimates that each “call” takes between 0.5 and 2 seconds to complete. So you need to consider every “call” your page is required to make: is it necessary? Can you have your page fulfill its function without that particular object?

Andy gives us a real-life example, the prototype of Web advertising producer Elivad.com‘s home page. The original home page had seven graphics with rollovers, for a total of 14 server calls, and 6 other calls for style sheets, JavaScripts, and the page itself. The page took about 15 seconds to load at 56k.

After optimization — the conversion of images and JavaScript rollovers into text using CSS rollovers, conversion of buttons into text links with colored backgrounds, consolidation and optimization of images, and optimization of JavaScript and style sheets — the page was able to cut its server requests from 20 to 6, speeding the load time to 6 seconds on a 56k modem. By eliminating the JavaScript rollover code, the HTML code itself was slimmed down by 41%, even accounting for the slightly larger CSS code (due to CSS rollovers added to the navigation bar). The page is just as functional, and as it loads essentially twice as fast (averaging 6 seconds on a 56k modem), it will attract and retain substantially more visitors (see pgs. 50-53).

But, you say, my page has several dozen server calls and it doesn’t take 15 seconds to load! Maybe not, but are you sure? Are you testing your page on a 56k dialup connection, or are you assuming that everyone is using the broadband or T1 connection you’re using? And we know that modern browsers and servers are able to send out multiple, simultaneous requests to speed download time for each call. But remember, “even with HTTP keep-alive, each round trip adds more time because the message has to traverse the Internet from client to server and back again” (p. 53).

This concept is doubly important when considering external files in the <HEAD> of your document. Any style sheets and JavaScript in the <HEAD> of a page must be processed before anything displays visually; pages with multiple CSS and JavaScript files can take an abominably long time to process, and the whole time your site visitors sit and stew, waiting for something — anything — to happen.

Cleaning Up the Code

I’m assuming that none of you are using one of the BloatCode Specials such as Microsoft’s Front Page to produce your pages. If you are, then you’re so far out of bounds that this article can’t help you much.

All I can tell you is that for a brief time I was employed by a large corporation’s Web design team to help optimize and standardize their internal technical “help” pages. Half of my time was spent taking the machete to pages produced in Front Page. I was usually able to get rid of 50-80% of the code without affecting the display of the page one iota (though I’m told that FP2000 and later editions are much less prone to bloat). In other words, if you’re using an old copy of MSFP (or another BloatCode Special — there are plenty out there) to produce your pages, find another alternative!

The great majority of visitors can’t read HTML and don’t have a clue whether code is good or bad, they’re just interested in good content and navigation. — Andrew Starling

One of the biggest criticisms of some of the optimization techniques Andy provides is that it makes it hard for those who peruse the source code to read and modify it. True enough, but is that reason not to streamline and optimize your code anyway? Most all of your site’s visitors aren’t going to be eyeballing your code — they couldn’t care less. As for your fellow designers, they’ll just have to buckle down and deal with it — it’s worth the minimal extra aggravation for lower bandwidth and lower bailout rates.

Removing Line Returns

Here’s a perfect example of giving up aesthetically pleasing code in favor of efficiency. Browsers don’t care if you have a return after each command or not; removing the line returns can significantly reduce your file size. Here’s an example from page 48:

<TABLE>   

<TR>   

<TD>speed</TD>   

</TR>   

<TR>   

<TD>me</TD>   

</TR>   

<TD>up</TD>   

</TR>   

</TABLE>

becomes:

<TABLE><TR><TD>speed</TD></TR><TR><TD>me</TD></TR>   

<TD>up</TD></TR></TABLE>

giving you an 11% reduction in file size. It’s not as pretty, but it looks exactly the same when displayed. Is it worth the sacrifice in code aesthetics? You decide.

Choosing the Right DOCTYPE: Strict vs. Quirky

An HTML page using the “Strict” standard will parse faster than one using the “Transitional” standard, and much, much faster than one using an older standard or one without a DOCTYPE at all. See my previous article for SitePoint, Fundamentals of Web Design, for a further explanation of DOCTYPES, and visit Mozilla’s DOCTYPE Sniffing page for details of the various standards and how browsers such as Mozilla decide which DOCTYPE is being employed.

Of course, a page using the Strict standard must be written in strict HTML 4.01 — no deprecated elements. A page written in strict HTML 4.01 with all closing tags employed will render faster than a similar page using deprecated elements and “quirky” HTML, as the browser has to do less work — even though it will be slightly larger because of the use of all closing tags (more on that later). The nice thing about this is that it also brings us one step closer to being compliant with XHTML standards …which is a whole different subject.

Whitespace

“Whitespace” in HTML code — indents, skipped lines, and the like — is strictly for ease of use by the designer, and the odd bird who views the code. It does nothing for the way the code displays, and can actually slow down the loading time. Here’s a simple example from p. 53-4. Prepare to be amazed at how much the code size is lowered.

<TABLE   ID='whitespace-repository'   WIDTH="800">    

  <TR>    

    <TD>speed</TD>    

    <TD>me</TD>    

    <TD>up</TD>    

  </TR>    

<TABLE>

becomes

<TABLE ID='whitespace-repository' WIDTH="800">    

<TR>    

<TD>speed</TD>    

<TD>me</TD>    

<TD>up</TD>    

</TR>    

<TABLE>

or better yet:

<TABLE ID='whitespace-repository' WIDTH="800"><TR>    

<TD>speed</TD><TD>me</TD><TD>up</TD></TR><TABLE>

This final example saves over 50% of the file size over the original.

Exception: some JavaScript requires whitespace in certain instances. Don’t try to optimize JavaScript unless you know what you’re doing.

Comma-Delimited Attributes

A few tags, most commonly the <KEYWORDS> META tag, the <MAP> coordinate attribute, and the <STYLE> tag, allow comma-delimited lists. Browsers and search engines both ignore the spaces after the commas. You can save precious file size by eliminating the spaces. Again, it isn’t as easy on the eye of the folks perusing the code, but everyone else will reap the benefits.

Here’s an example, cribbed from pgs. 54-55:

<STYLE TYPE="text/css">    

<!--    

body {    

font-family: arial, helvetica, sans-serif;    

font-size: 1.1em;    

}    

-->    

</STYLE>

becomes:

<STYLE TYPE="text/css">    

<!--    

body{    

font-family:arial,helvetica,sans-serif;    

font-size:1.1 em;    

}    

-->    

</STYLE>

or even:

<STYLE TYPE="text/css"><!-- body {font-family:     

arial, helvetica, sans-serif;font-size:1.1 em;}--></STYLE>

Another nice reduction in file size for a small loss in aesthetics.

Department of Redundancy Department

You’d be surprised how many tags and attributes are redundant and can be eliminated without affecting how the code runs. Deprecated tags such as <FONT> and <BASEFONT>, <CENTER>, <STRIKE>, and <U> can be handled more efficiently with style sheets. So can many of the variety of <BODY> attributes — BGCOLOR, BACKGROUND, LINK, ALINK, VLINK, and so forth. The more you rely on style sheets, the more you’re compliant with XHTML as well.

Tables are a great place to find redundant elements. A simple example, cribbed from p. 56, shows us how to tighten up our table code.

You could use this:

<TABLE>    

  <TR>    

    <TD ALIGN="right">tastes great</TD>    

    <TD ALIGN="right">less filling</TD>    

    <TD ALIGN="right">burma shave</TD>    

  </TR>    

</TABLE>

but this works better:

<TABLE>    

<TR ALIGN="right">    

<TD>tastes great</TD>    

<TD>less filling</TD>    

<TD>burma shave</TD>    

</TR>    

</TABLE>

Even more space can be saved like this:

<style type="text/css">    

<!--    

table.tr.right{text-align:right;}    

-->    

</style>    

...    

<TABLE><TR CLASS="right"><TD>tastes great</TD>    

<TD>less filling</TD><TD>burma shave</TD>    

</TR></TABLE>

You can write a dozen more tables on this page using the same style sheet.

Eliminating Optional Quotes

Some attributes in HTML 4.01 can be unquoted. If the attributes only contain alphanumeric characters, hyphens, periods, underscores, and colons, then they can be left unquoted. If the attributes contain other characters, they must be quoted.

So this works:

<IMG SRC="t.gif" WIDTH=1 HEIGHT=1>

but this doesn’t:

<TABLE WIDTH=100%>

Yahoo!, the busiest site on the Web, omits quotes from its link tags. Other sites omit quotes entirely, violating the standard HTML recommendations but trusting in the individual browser to handle the code anyway. Usually this works …usually (p. 57).

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.

Conclusion

There’s a great deal more in Andy’s book than this short column attempts to cover. While you’re welcome to use any and all of the techniques covered in these pages, don’t think that this is everything you can do to streamline your HTML code. This column merely scratches the surface.

I understand that many of the techniques in this column, and in Andy’s book, go against the grain of the typical Web developer. We’ve been told to write elegant, usable code that looks as good on the code end as it does displayed in the browser. Some of the techniques I’ve passed along in these pages rub me the wrong way, too.

However, striving for Web efficiency isn’t an “extra” that can be put on the back burner, to be done “when we get around to it.” It’s something that must be addressed from the outset of any new page creation, and something that must be considered for any page already created. If these techniques can help your site users get more enjoyment and more use out of their visits to your page, then they’re worth considering. Think about them before you dismiss them out of hand because they’re not what you’re used to — their benefits may well outweigh the cost in “HTML aesthetics.”