How to Optimize Your HTML

Optimizing HTML is a matter of using the fewest number of bytes to deliver a valid page that renders properly. There are a number of techniques you can use to shrink your HTML. These include removing whitespace, omitting optional closing tags and quotes, removing redundant tags and attributes, cutting comments, and minimizing HTTP requests . This last point is important to keep in mind. We'll delve more deeply into graphics in Chapter 12, "Optimizing Web Graphics." First, let's start with the DOCTYPE declaration.

Step 1: Choose the Right DOCTYPE

As far as speed goes, there are two things to consider when choosing a DOCTYPE and coding style: DOCTYPE switching and parsing speed. By now you've seen the three DTDs you can use at the top of HTML documents (see Chapter 5, "Extreme XHTML" for details). Depending on the DTD that you choose and some internal parameters the browser developers have chosen , browsers switch to one of two or three "modes" to render your HTML document: standards, almost standards, and quirks modes. For more information on "almost standards" mode, see http://www.mozilla.org/docs/web-developer/ quirks / doctypes .html.

Standards Mode versus Quirks Mode

The "standards" mode can be fastest because the parsing code is smaller and less complex. The browser is most likely to invoke this mode when you use the strict DTD. Keep in mind that there's not a one-to-one relationship between the DOCTYPE you choose and the mode browsers switch into, although they do have an influence. ^[13] For more details, see Matthias Gutfeldt's article on DOCTYPE switching, available at http://gutfeldt.ch/matthias/articles/doctypeswitch.html.

^[13] Eric Meyer, "DOCTYPE Grid" [online], (Cleveland, OH: Meyerweb.com, 2002), available from the Internet at http://www.meyerweb.com/eric/dom/dtype/dtype-grid.html.

There are some tradeoffs, however. Strict means just that strict. No deprecated tags allowed. Some designers may have to rethink how they lay out pages. A common method some authors use is to first markup and validate the structure of their documents and then add presentation in the form of style sheets.

As you can imagine, quirks mode by its very nature is slower to parse HTML than standards mode. The parsers for quirks mode are necessarily more complex to allow for all the permutations of looser legacy markup.

Coding Style

For HTML, your coding style can affect download and display speed. When you use the strict DTD and close all tags, the browser can use a faster parsing algorithm and does less work inserting and matching tags. Your pages will render faster but will be slightly larger because of the closing tags. On the other hand, omitting optional closing tags can yield smaller pages that will download faster but render slightly sloweryet they will still be valid. Either method is a valid approach, but the former makes for a smoother transition to XHTML. One approach is to fully optimize home pages (omit optional closing tags and quotes) and create well- formed interior pages (use XHTML-like HTML with closing tags and fully qualified attributes).

Step 2: Minimize HTTP Requests

Because each HTTP request takes an indeterminate amount of time, it's important to minimize the number of HTTP requests per page. As discussed earlier, the browser issues HTTP GET requests, and the HTTP server responds with the requested object. Each objectincluding HTML pages, images and multimedia, external style sheets, and JavaScripttakes one HTTP request. To get a better idea of how to improve the conversation between client and server, let's take a look at a real-world example. Let's optimize the prototype of Elivad.com's home page (see Figure 3.1). Elivad claims to boost click-through rates for online ads.

Figure 3.1. Elivad.com prototype with graphic rollovers.

Here's an abbreviated log file of Elivad.com, which uses graphic rollovers after loading this page:

 192.168.1.1 - - [07/Sep/2002:11:07:24 -0400] "GET / HTTP/1.1" 200 6289 192.168.1.1 - - [07/Sep/2002:11:07:26 -0400] "GET /css/company.css HTTP/1.1" 304 503 192.168.1.1 - - [07/Sep/2002:11:07:27 -0400] "GET /pics/logo.gif HTTP/1.1" 304 10582 192.168.1.1 - - [07/Sep/2002:11:07:28 -0400] "GET /pics/toptext450.gif HTTP/1.1" 304 6855 192.168.1.1 - - [07/Sep/2002:11:07:28 -0400] "GET /pics/spacer.gif HTTP/1.1" 304 43 192.168.1.1 - - [07/Sep/2002:11:07:28 -0400] "GET /pics/home_off.gif HTTP/1.1" 200 305 192.168.1.1 - - [07/Sep/2002:11:07:29 -0400] "GET /pics/map_on.gif HTTP/1.1" 200 421 192.168.1.1 - - [07/Sep/2002:11:07:29 -0400] "GET /pics/get_on.gif HTTP/1.1" 200 468 192.168.1.1 - - [07/Sep/2002:11:07:29 -0400] "GET /pics/demo_on.gif HTTP/1.1" 200 400 192.168.1.1 - - [07/Sep/2002:11:07:29 -0400] "GET /pics/faq_on.gif HTTP/1.1" 200 314 192.168.1.1 - - [07/Sep/2002:11:07:29 -0400] "GET /pics/support_on.gif HTTP/1.1" 200 424 192.168.1.1 - - [07/Sep/2002:11:07:29 -0400] "GET /pics/about_on.gif HTTP/1.1" 200 460 192.168.1.1 - - [07/Sep/2002:11:07:30 -0400] "GET /pics/home_on.gif HTTP/1.1" 200 360 192.168.1.1 - - [07/Sep/2002:11:07:30 -0400] "GET /pics/home_image2.gif HTTP/1.1" 200  21004 192.168.1.1 - - [07/Sep/2002:11:07:30 -0400] "GET /pics/map_off.gif HTTP/1.1" 200 360 192.168.1.1 - - [07/Sep/2002:11:07:30 -0400] "GET /pics/get_off.gif HTTP/1.1" 200 401 192.168.1.1 - - [07/Sep/2002:11:07:30 -0400] "GET /pics/demo_off.gif HTTP/1.1" 200 352 192.168.1.1 - - [07/Sep/2002:11:07:32 -0400] "GET /pics/faq_off.gif HTTP/1.1" 200 281 192.168.1.1 - - [07/Sep/2002:11:07:32 -0400] "GET /pics/support_off.gif HTTP/1.1" 200 366 192.168.1.1 - - [07/Sep/2002:11:07:32 -0400] "GET /pics/about_off.gif HTTP/1.1" 200 392 

Notice the number of HTTP requests. Each corresponds to an image, an external CSS or JavaScript file, or the HTML file itself. The total number of bytes transferred is 50,580 bytes, with 20 HTTP requests. The seven graphic rollovers account for 14 of these HTTP requests, two for each item.

This home page takes about 15 seconds to download at 56Kbps. This is due to the total size of the page (50,580 bytes at 4,500 bytes per second) and the latency introduced from HTTP requests. Each HTTP request takes an indeterminate about of time, depending on network conditions. Jakob Nielsen found that on average it takes about 1/2 to 2 seconds per HTTP request. ^[14]

^[14] Jakob Nielsen, Designing Web Usability: The Practice of Simplicity (Indianapolis, IN: New Riders Publishing, 2000).

An Optimized Example

Now let's take that same page and optimize it. By converting images and rollovers into text, consolidating and optimizing images, and optimizing JavaScripts and style sheets, you can minimize the number of requests and speed up your pages. By replacing the graphic rollovers and JavaScript with CSS rollovers and any buttons with links and colored backgrounds, you can eliminate the majority of images. So instead of this:

 <td align="center"><a href="index.html" onMouseOut="imageout(IMG01, 'pics/home_off.gif')"  onMouseOver="imagein(IMG01, 'pics/home_on.gif'); return true"  target="_top"><IMG NAME="IMG01" SRC="pics/home_off.gif" WIDTH="64" HEIGHT="22" BORDER="0"  ALT="HOME"></A></td> <td align="center"> <a href="about/" onMouseOut="imageout(IMG02, 'pics/about_off.gif')" onMouseOver="imagein(  IMG02, 'pics/about_on.gif'); return true" target="_top"><IMG NAME="IMG02" SRC="pics/about_off.gif" WIDTH="105" HEIGHT="22"  BORDER="0" ALT="ABOUT US"></A></td> 

Do this:

 .buttons a:hover {background:#fff; color: blue;}  ... <td align="center" class="buttons">HOME</td> <td align="center" class="buttons"><A HREF="about/">ABOUT&nbsp;US</A></td> 

Here's the same page after replacing the graphic rollovers with CSS (see Figure 3.2).

Figure 3.2. Elivad.com after optimization.

Here's the log file after loading this optimized page:

 192.168.1.1 - - [07/Sep/2002:11:06:22 -0400] "GET /index_new.html HTTP/1.1" 200 4083 192.168.1.1 - - [07/Sep/2002:11:06:24 -0400] "GET /css/company2.css HTTP/1.1" 304 544 192.168.1.1 - - [07/Sep/2002:11:06:25 -0400] "GET /pics/logo.gif HTTP/1.1" 200 3468 192.168.1.1 - - [07/Sep/2002:11:06:25 -0400] "GET /pics/spacer.gif HTTP/1.1" 200 43 192.168.1.1 - - [07/Sep/2002:11:06:25 -0400] "GET /pics/toptext450.gif HTTP/1.1" 200 1505 192.168.1.1 - - [07/Sep/2002:11:06:25 -0400] "GET /pics/home_image.gif HTTP/1.1" 200 12384 

Notice that the number of HTTP requests decreased from 20 to 6. By replacing the graphic rollovers with CSS, you eliminate 14 HTTP requests. The page now weighs in at 22,027 bytes and takes about six seconds to load on a 56K modem. The HTML is 41 percent smaller, having eliminated the JavaScript rollover code. The CSS is slightly larger, because of the CSS rollover added to the navigation bar links, but that's a small price to pay for the reduced HTTP request load. The images were also optimized to save space. Overall the page feels much faster and has the same functionality as before. Most importantly, we've brought the load time down below eight seconds.

Modern browsers and servers (HTTP 1.1) send out multiple simultaneous requests to save time. 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. Each hop in this path adds latency due to packet loss and network load.

By minimizing the number of HTTP requests required by your pages, you can speed up their display, and lower delay variability. This is especially important for any external files in the head of your document, which must be processed before the visible body content. Multiple external CSS and JavaScript files are now common, but they can dramatically slow down your pages. You'll learn how to defer , consolidate, and eliminate these external files in Chapter 7, "CSS Optimization," and Chapter 9, "Optimizing JavaScript for Download Speed."

Step 3: Remove Whitespace

The average web page has between 20 and 35 percent extra whitespace, according to Insider Software (http://www.insidersoftware.com/) and WebTrimmer (http://www.glostart.com/webtrimmer/). Browsers don't care how pretty your markup is; they're just looking between tagsreal or implied . Those extra spaces, tabs, and returns make your markup easier to read but slower to display. Spaces between and inside tags can also be removed. Indents are typically used by programmers and WYSIWYG editors to make the markup more legible and the document's structure more obvious.

So instead of this:

 <table  id="whitespace-repository"  width="800">        <tr>             <td>speed</td>             <td>me</td>             <td> up </td>       </tr> </table> 

Do this:

 <table id="better" width="800">  <tr> <td>speed</td> <td>me</td> <td>up</td> </tr> </table> 

Or even better:

 <table id="best"><tr><td>speed</td><td>me</td><td>up</td></tr></table> 

Removing whitespace and tightening up things saves over 50 percent for this code snippet.

This whitespace is entirely unnecessary (with some exceptions for JavaScript) for browsers rendering HTML. They see the HTML file as a stream of bytes with tags interspersed around data. Indents and spaces before or at the end of lines are simply wasted bandwidth and are ignored by browsers. If necessary, you can re-beautify your markup for editing by using sophisticated text editors like BBEdit and Homesite or by using regular expressions or short shell scripts.

Step 4: Tighten Up Comma-Delimited Attributes

Some tags allow a comma-delimited list for attribute values. The most common are the <keywords> meta tag, the <map> coordinate attribute, and the <style> tag. Browsers and search engines ignore leading spaces before comma-delimited attributes. You can save some space by omitting spaces when using commas or omitting commas altogether for the <keywords> meta tag. See Chapter 15, "Keyword Optimization," for more details.

The style tag allows comma-delimited lists. The same principle applies.

So instead of this:

 <style type="text/css">  <!-- body {       font-family: arial, helvetica, sans-serif;         font-size:   1.1 em; } --> </style> 

Do this:

 <style type="text/css">  <!-- body{ font-family:arial,helvetica,sans-serif; font-size:1.1em; } --> </style> 

Or even better:

 <style type="text/css"><!-- body{font-family:arial,helvetica,sans-serif;font-size:1.1em;}  --></style> 

Sharp-eyed readers will see that there is one additional optimization that can be made to this style sheet. For more details, see Chapter 7, "CSS Optimization."

Step 5: Omit Redundant Tags and Attributes

In many cases, attributes or tags are redundant and can be safely eliminated. Elements (formatting or otherwise ) need to be placed only around blocks of HTML text. Here's an example:

 <ol>  <li><font size="+1">Speed</font></li> <li><font size="+1">Me</font></li> <li><font size="+1">Up</font></li> </ol> 

This code becomes the following (which is invalid markup):

 <font size="+1">  <ol> <li>Speed</li> <li>Me</li> <li>Up</li> </ol> </font> 

Even better, get rid of the deprecated <font> tag and remove optional closing tags, like this:

 <style type="text/css">  <!-- .plus{font-size:1.1em;} --></style> ... <ol class="plus"><li>Speed<li>Me<li>Up</ol> 

You could use an id instead of a class attribute to identify the list element here; however, id names must be unique within the document and cannot be used on multiple elements like class can.

Redundant Attributes

Redundant attributes generally specify the default attribute value for that particular element. These include align="left" for p , h1 , h2 and other heading tags, table , tr , and td elements and border="0" for non-linked images.

Tables are a common place to find redundant attributes. The td tag can be aligned individually, but you also can control the alignment of an entire row by using the tr tag, which saves space. For strict XHTML compliance, use style sheets to align the contents of tables.

So instead of this:

 <table>        <tr>             <td>tastes great</td>             <td>less filling</td>             <td>burma shave</td>        </tr> </table> 

Do this:

 <table>        <tr>             <td>tastes great</td>             <td>less filling</td>             <td>burma shave</td>        </tr> </table> 

Or even better:

 <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> 

Step 6: Omit Optional Quotes, If You Dare

The HTML 4.01 specification allows certain attribute values to be unquoted. Attribute strings that contain only alphanumeric characters (A-Z, a-z, 0-9), hyphens, periods, underscores, and colons can be unquoted. Any attribute values that include other characters must be quoted.

This means that you can do this:

 <img src="t.gif" width=1 height=1> 

But not this:

 <table width=100%> 

Values with spaces, symbols, or links require quotes in HTML. For example:

 <a href="/index.html"> 

Browsers are quite liberal in what they accept for HTML markup. Some sites take advantage of this and omit quotes entirely, violating the HTML Recommendation. Yahoo!, the busiest site on the web, omits quotes from their link tags. For example:

 <font size=3 face=arial><a href=r/ci><b>Computers & Internet</b></a></font><br><a href=r/  in>Internet</a>,  <a href=r/ww>WWW</a>, <a href=r/sf>Software</a>, ... 

Note the lack of quotes here. Also notice those funny -looking URLs that start with r/ . To abbreviate their URLs, Yahoo! uses redirects to save bandwidth. We'll discuss how to use automatic URL abbreviation in Chapter 4, "Advanced HTML Optimization," and go into more detail in Chapter 17, "Server-Side Techniques."

Omitting quotes for URLs works on all current browsers and saves Yahoo! three percent off their home page, ^[15] but it is invalid HTML. However, there's no guarantee that future browsers won't require quotes around links. I recommend that you quote all attribute values that require them, and to get ready for XHTML, you may want to consider quoting all attribute values regardless of whether the quotes are needed in HTML.

^[15] Andrew King, author calculation (Feb. 8, 2002). Yahoo.com's home page with link quotes added = 16,360 bytes; without quotes (as is) = 15,869 bytes, a three percent savings.

NOTE: If you are adventurous, you can learn more about Extreme HTML Optimization at http://www. webreference .com/authoring/languages/html/optimize/.

Step 7: Omit Optional Closing Tags

A number of elements in HTML don't technically require closing tags because the elements that follow them imply closure. These include p , li , option , and even body and html . Even table row and data closing tags ( </td> and </tr> ) are not technically required by the HTML specification, but Netscape 3 does not render tables properly without them.

So instead of this:

 <select ...>  <option>Numero Uno</option> <option>Numero Dos</option> etc. </select> 

Do this:

 <select ...>  <option>Numero Uno <option>Numero Dos  etc. </select> 

Even better:

 <select ...><option>Numero Uno<option>Numero Dos</select> 

Keep in mind that this practice violates XHTML where all tags must be closed and attributes fully qualified. Early versions of Netscape 6 also can fail to properly apply CSS and execute dynamically written external JavaScripts when elements are improperly nested. So, make sure that your elements are nested properly and your HTML is validated . ^[16]

^[16] Andrew King, "JavaScripting Netscape 6: No More Sloppy Code" [online], (Darien, CT: Jupitermedia Corporation, 2001 [cited 13 November 2002]), available from the Internet at http://www.webreference.com/programming/javascript/netscape6/.

Again, this is a tradeoff between page size and rendering speed. Using HTML with all tags closed makes your pages render slightly faster, whereas using HTML without optional closing tags makes your pages download faster but still validate. At current bandwidth-to-CPU-speed ratios, bandwidth is the limiting factor.

Step 8: Minimize Colors and Character Entities

You can save some space by optimizing your color references and character entities. In HTML 4.01, each offers numeric references and named references to colors and character entities. In some cases, the named reference is shorter; in others, the numeric reference is shorter. Choose the shortest reference to save a few bytes. As color attributes are deprecated in HTML 4.01 and XHTML, you can use style sheets to specify colors to save even more space, because in some cases, they can be optimized to use shorthand hexadecimal colors.

Character References

For characters outside of the default (or specified) character encoding scheme, you can use SGML character references to specify special characters.

In HTML, you can specify character entities in two ways:

• Numerically (either decimal [i.e., &#169 ;] or hexadecimal)

• Using a named character entity (i.e., &copy ;)

In some cases, using the numeric reference is shorter than the named reference and vice versa (that is, reg and deg ). To see the full list of character entities, go to http://www.w3.org/TR/html401/sgml/entities.html.

Colors

Color attributes can be represented numerically or with one of 16 named colors. In HTML, you specify colors using RBG hexadecimal triplets, like #RRGGBB:

• The first pair of digits specifies the red intensity.

• The second pair specifies the green intensity.

• The third pair specifies the blue intensity.

You also can specify colors using named colors. Because Internet Explorer 2 defined only 16 colors, there are 16 colors in the HTML 4.01 specification. Color names are case-insensitive. For example:

 Blue = "#0000FF" 

The W3C has deprecated the use of colors in HTML attributes in favor of style sheets, however, so this information applies primarily to style sheets. Named colors outside the 16 listed in the specification are not recommended because different browsers support different numbers and types of named colors. (Remember the infamous 216 browser-safe colors?) The hexadecimal values are unambiguous and can use fewer characters than their named equivalents, although some named colors use less than their hex equivalents ("red," for example). The sixteen named colors are listed here:

• Black = "#000000"

• Silver = "#C0C0C0"

• Gray = "#808080"

• White = "#FFFFFF"

• Maroon = "#800000"

• Red = "#FF0000"

• Purple = "#800080"

• Fuchsia = "#FF00FF"

• Green = "#008000"

• Lime = "#00FF00"

• Olive = "#808000"

• Yellow = "#FFFF00"

• Navy = "#000080"

• Blue = "#0000FF"

• Teal = "#008080"

• Aqua = "#00FFFF"

In modern browsers, version 3 and up, except for buggy behavior in Mac IE3, ^[17] RGB triplets can be abbreviated if each of the R, G, and B hex pairs are the same, thus:

^[17] Eric A. Meyer, "WebReview.com's Style Sheet Reference Guide" [online], (Manhasset, NY: CMP Media, 2002), available from the Internet at http://style.webreview.com.

 Blue = "#00F" is equivalent to "#0000FF" 

The browser automatically expands three-character colors into six by duplicating the R, G, and B values. You'll learn more about color abbreviation in Chapter 7, "CSS Optimization." For more information, see the HTML 4.01 specification. ^[18]

^[18] Dave Raggett, Arnaud Le Hors, and Ian Jacobs, "HTML 4.01 Specification" [online], (Cambridge, MA: World Wide Web Consortium, 1999), available from the Internet at http://www.w3.org/TR/html401/.

Step 9: Cut the Comments

HTML comments are often used to mark major sections of documents. These comments can help teams of designers locate insertion points for new or changed content. Unfortunately, users have to download your entire HTML file including your comments, and browsers don't display them. Therefore, comments should be abbreviated.

So instead of this:

 <!-- #### Start left column here #### --> 

Do this:

 <!-- left col --> or <!-- lcol --> or even <!-- l --> (could use an abbreviation map  here) 

Abbreviating your comments can dramatically reduce file sizes, especially for heavily commented pages. This technique saves 31 bytes, or 75.6 percent (31/41).

Embed Labels in Elements

A more efficient technique is to eliminate comments entirely. Instead of peppering your code with placeholding comments for other designers to key off of, eliminate the comments by shunting them into surrounding elements. For example, you could shunt the preceding comment label into an element's id , like this:

 <table id="left-column"> or <table id="lcol"> or even <table id="l">  <div id="left-column"> or <div id="lcol"> or even <div id="l"> 

This technique of shunting labels into elements saves 41 bytes or 85 percent over the original (41/48).

By using a template system, you can include any comments you need within the template. A script could then periodically strip out all comments from the page, and output the final optimized page. We use this technique on Webreference.com's home page. ^[19]

^[19] King, "Evolution of a Home Page" [online].

You can eliminate comments and id labels entirely. Using SSI or a content management system, you can merge separate files into one optimized template and have the best of both worlds . Editors can update only the parts of the page that need to change, and the server or content management system can assemble the optimized page.

Pages Are Not Digital Dumping Grounds

HTML files, especially crucial high-traffic pages, are not digital blackboards where designers can freely scrawl comment graffiti. They are not repositories for old or seldom-used commented-out blocks of markup. HTML documents should be designed to make it easy for users to get your information, not for the convenience of designers.

Step 10: Minimize alt Values

alt values are important for a number of reasons, not the least of which is the fact that there are over 49 million disabled people in the U.S. alone. ^[20] Vision-impaired users rely on alt values to navigate graphics-rich sites. Frequently we're seeing graphics-only designs with no alt values. This makes for a beautiful slow-loading site that is not usable with graphics turned off. Available for the applet , area , and img elements, alt attribute values can be optimized and eliminated altogether for non-functional graphics.

^[20] Total number of disabled in the U.S. is 49,746,248 out of 257,167,527 total people. Or nearly 1 out of every 5 people in the U.S. has a disability. (U.S. Census, 2000. Available from the Internet at http://www.census.gov/.)

Real-World Example

Here's a real-world example of comments run wild from PopularMechanics .com:

 <!-- END LEFT COLUMN NAVIGATION BAR MARKETING AREA, "button_one"  -->          <!-- BEGIN LEFT COLUMN NAVIGATION BAR MARKETING AREA,  "button_two" -->          <a href="http://popularmechanics.com/cooper"  target="new"><img src="/images/button_two.gif" border="0"></  a><table name="left_col_spacer_table4" width="124" height="15"  border="0" cellspacing="0" cellpadding="0"><tr><td width="124"  height="15"><img src="/images/clear.  gif" width="124" height="15" border="0"></td></tr></table>                 <!-- END LEFT COLUMN NAVIGATION BAR MARKETING  AREA, "button_two" -->         <!-- END ADDITIONAL/NEW 2 LEFT COLUMN NAVIGATION BAR  MARKETING AREAS -->         <!-- xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx xxxxxxxxxx  xxxxxxxxxx xxxxxxxxxx -->         <!-- END LEFT COLUMN NAVIGATION BAR MARKETING AREA --> 

So instead of this:

 <img src="/images/global/transparent-gif1x1.gif" alt="transparent gif" border="0"> 

Do this:

 <img src="t.gif" alt=""width="1" height="1"> 

For functional graphics, alt values should be descriptive, not generic. Imagine that you are a visually impaired person surfing your sitewhat would you want to know about that image?

So instead of this:

 <img src="/art/webreference_logo.gif" alt="our logo"> 

Do this:

 <img src="/l.gif" alt="webref.com" width="125" height="60"> 

Make your alt values short and sweet, and don't try stuffing them with too many keywords. For client-side image maps, alt values allow non-graphical browsers to present the map as a list of links identified by the alt labels.

Accessibility and Optimization

The Americans with Disabilities Act includes Section 508, which provides accessibility rules for electronic and information technology that is created or procured by a U.S. Federal agency (http://www.section508.gov/). These rules/laws have been passed to ensure equal access for all to publicly available information. By providing alternative content, you can remove barriers for people with disabilities and maximize your potential audience. Optimization does not preclude accessibility; it actually enhances it if done properly (see the W3C's "Web Accessibility Guidelines" at http://www.w3.org/WAI/). Pages that use text to convey information display faster and are more easily read by people with or without disabilities .

Step 11: Minimize the head

Browsers interact with servers in discrete- sized messages and parse HTML pages sequentially. The head must be parsed before the rest of your page is rendered. By minimizing the size of the head of your pages, you can speed your content's initial display. This is especially important for busy home pages. Excess CSS or JavaScript, especially multiple external files, can both delay content display and lower your page's search engine relevance.

Minimize meta Tags

meta tags are HTML tags that you place in the head section of your page. They let you specify metadata information about your document in a variety of ways. meta tags are designed to help automated agents process metadata about your document and to help show where your document fits into the web. Many sites overuse meta tags, however, by stuffing in data that could best be omitted or handled more efficiently by the server.

The meta element identifies the properties of a document (such as author, expiration date, a list of keywords, and so on) and assigns values to those properties. For example, one way to specify the author of a document is to use the meta element, as follows :

 <meta name="Author" content="Dr. Seuss"> 

The meta element specifies a property ("Author") and assigns a value to it ("Dr. Seuss").

meta tags can be used to specify default scripting, style sheet languages, or character sets. They also can be used to specify keywords to help search engines classify your pages. Additionally, meta tags can be used to augment HTTP headers sent from the server (although most of these are redundant) and have even been extended to include taxonomy classification systems like the Dublin Core . ^[21]

^[21] DCMI, "Dublin Core Meta Data Initiative" [online], (Dublin, OH: DCMI, 1995), available from the Internet at http://www.dublincore.org/.

Here's a list of some popular meta tags:

 <head>        <meta http-equiv="Content-Type" CONTENT="text/html; charset=us-ascii">       <meta http-equiv="Content-Script-Type" CONTENT="text/javascript">       <meta name="resource-type" CONTENT="Document">       <meta name="distribution" CONTENT="Global">       <META NAME = "keywords" CONTENT = "broadband user-friendly customer service...">       <META NAME = "Description" CONTENT = "Megatelco is the definitive site...">       <META NAME = "ROBOTS" CONTENT="ALL">       <META NAME = "Copyright" CONTENT = "2002, 2003, 2004 Company.com">       <META NAME = "Author" CONTENT = "author name">       <META NAME = "Date" CONTENT = "2003-1-1">       <META http-equiv="Expires" content="Mon, 1 Jan 2004 12:00:00 GMT">       <META HTTP-EQUIV="PICS-Label" CONTENT = '(PICS-1.1 "http://www.rsac.org/ratingsv01.  html" l gen true comment "RSACi North America Server" by "[e-mail]" for "http://company.com/" on "2002.12.31T08:13-0800" r (n 0 s  0 v 0 l 0))'>       <META NAME="generator" CONTENT"Microsoft FrontPage 7.0"> </head> 

The only meta tags you really need to use are the description and keywords tags, and possibly the default scripting language. All the others are superfluous or can be handled more efficiently by server settings.