Article
Practical Web Design - Speed Up Your Site
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.