COM271, Week 11

Web Site Optimization

Syllabus | Table of Pages | Assignments | References and Useful Links

The following notes are drawn from Andrew B. King's Speed Up Your Site: Web Site Optimization. New Riders Press, 2003, 496 p.

They Want it Now!

User expectations / user demands: Simply, internet users expect speed. Hit the link, expect the new page. Nothing happening immediately (<1 second) starts immediate impatience. Seconds count, and users don't want to give you many of them. If I can't get a page loaded in, say, 7 or 8 seconds, maybe I should go back and look for a different page. It's that bad. People want a site that is useful, functional (does things quickly and with the least amount of work from the user), flexible, easy to understand (learnable), successful (users gets what they came for), and likable (users feel good about the site). Some goals:

Effective—Display in <8 seconds on the slowest connections (56K modem)
Learnable—Users find what they came for in <30 seconds
Flexible—Find things by browsing or searching
Attitude—Users rate the site good or above on a very good to very bad 5-point scale.
Usability—Understand and follow Jakob Nielsen's usability checklists

Note that as technology moves forward, most people move from slow modems to ISDN or T1 lines. T1 (Cox, etc.) are about 50 times faster than modems. A 30kb page will be ok at the slowest modems; 1.5MB should be tolerable on Cox.

If they don't get it now, users will begin to bail out. Guidelines vary, but keeping page loading to under 7-8 seconds seems to be a key, with a higher percentage bailing as you approach and exceed this threshold.

Download speed measures: There are several services that will provide information on download times for individual pages. Google "download speed test." I tried www.gomez.com, for example, and this gave me a report on response time (from one out of two dozen possible locations): my home page downloaded in 1.37 seconds, which isn't bad! This should be repeated at different times of the day (e.g., 3pm is likely to be slower as this is a peak internet usage time).

Structural speed: XHTML

XHTML optimization means minimizing XHTML file size and complexity to make pages display fast. Optimization begins with careful separation of structure (html) content from layout (css). Dynamic scripts should be linked to external files, particularly if the scripts are used on multiple pages; once the scripts file has been downloaded with the first page, it is cached locally and not downloaded again, saving time. All parts of a page must come down via TCP/IP as a stream of information. The longer the stream, the longer it takes to download. Optimization includes the following:

Choose the Right DOCTYPE: Your choice is standards, almost standards, or quirks modes. Standards is fastest because the browser does less parsing, assuming code is written carefully and by the rules. That means no deprecated tags (<font>, etc.); closing all tags, etc.
Minimize HTTP Requests: Each time your page needs an object, it requests if from the server (usually as a packet of several requests at one time). Objects include html pages, images and multimedia, external style sheets, and JavaScripts. Reduce these by converting images and rollovers (particularly graphic rollovers which require two images) to text, consolidating and optimizing images (smaller through more compressed jpeg or gif files, less color, etc.), and graphic buttons with links and colored backgrounds.)
Remove Whitespace: Most of your pages have 20-35% extra whitespace, used to make your markup prettier and easier to read. That's fine when you are developing the page, but it merely slows things down when you move into final production. Browsers don't use the whitespace. They skip it, looking for the next tag or bit of content, but the spaces are part of the download stream, and so just take up time. Crunch them by removing them as much as possible at the very end of your development cycle.
Tighten Up Comma-delimited Attributes: In <meta>, <map>, and <style> tags, attributes are common. Save spaces when using commas (or take them out altogether in the <meta> tag.
Omit Redundant Tags and Attributes: Remember that styles are inherited through the DOM tree. Instead of inserting styles on each element (e.g., <li>), style the container (i.e., <ul>)
Minimize Colors and Character Entities: Certainly, reduce all RGB triplets (e.g., #33cc00) into three-characters (i.e., #3c0) whenever possible.
Cut the comments: Ok, you needed comments to keep track of the complex code as you developed. Now it is developed; it works fine. Don't forget to kill the comments. If you want to keep a commented copy on your local development machine or development server, that's fine. But kill comments before going to the production server.
ALT: For non-functional graphics (background color blocks, etc.), use ALT=" ". For functional graphics (title gifs, etc.), keep the ALT text as simple as possible.
Minimize the head: Keep meta tags sparce. You don't need meta elements for author, expiration date, keywords, etc. If you use them, keep them simple. Common Meta tags include keywords, description, copyright, author, date, and generator. Not all are needed or useful. Only keywords and description really do anything useful for your site (they are vital for search engines, of course).

Tables: Complex tables are slow to render. A table will not begin to render until the browser knows how wide it is. If it contains tables within tables, the browser must resolve the size of each element, working outward from the innermost table to determine the size of each outward container. Nothing is rendered until this is complete, meaning that the page may sit there for seconds until the process is complete. The size of a table element <td> can be determined by the size of its content. If you provide width and height as attributes to the element, rendering can proceed independently of content. Even within tables, row groups can be allowed to render if they are enclosed in thead, tfoot, or tbody elements, something you may be forced to do for longer multi-page tables. Column groups <colgroup> allows specification of width or other attributes (set for each column using <col width="100px">, for example), so that the table can begin rendering as soon as the first row is downloaded. Or, simply break the table into subtables (say, every 10 rows), so that the first table will begin to render while the next is being determined. Consolidate table attributes (style the row instead of each element if possible, for centering, vertical alignment, etc.). Best, of course, is to style through CSS.

Perception: Remember that the user is experiencing the rendering. Allow part of the page (banner, navigation) to render independently of any long table content, letting the user see that the page is in fact rendering.

Forms: GET takes one less trip to the server than POST. If security is not an issue and form content is limited, using GET can mean faster form processing.

Menus: DHTML menus use javascript and often multiple images (rollovers) to provide user feedback for mouse operations (hover, click), including multi-tiered menus (drop-down, fly-out). These can be replaced with CSS.

URL's: Shorten your file and folder names. Use relative files instread of absolute in building hrefs.

Yslow

Yslow is a developer tool from Yahoo, available as a download from firefox . Yslow operates under Firebug, also available (necessary for Yslow) from mozilla (addons.mozilla.org/en-US/firefox/addon/firebug/?src=dp-dl-dependencies).

Yslow is designed to evaluate site speed based on a set of quantifiable rules. These are listed here, with links directly to the Yahoo site (developer.yahoo.com/performance/rules.html):