How to make your web pages load faster

Web page optimization streamlines your content to maximize display speed. Fast display speed is the key to success with your website. It increases profits, decreases costs, and improves customer satisfaction (not to mention search engine rankings, accessibility, and maintainability).

Streamlining transforms your pages to display navigable content faster, and to defer or delay off-site content. In this chapter, you'll learn how to reduce HTTP requests, convert to semantic markup to more easily style with Cascading Style Sheets (CSS), optimize graphics and multimedia, and defer or delay the loading of off-site content.

To maximize web page display speed, you can employ the following 10 techniques:

• Minimize HTTP requests.
  
• Resize and optimize images.
  
• Optimize multimedia.
  
• Convert Javascript behavior to CSS.
  
• Use server-side sniffing.
  
• Optimize Javascript for execution speed and file size.
  
• Convert table layout to CSS layout.
  
• Replace inline style with CSS rules.
  
• Minimize initial display time.
  
• Load Javascript wisely.

Using these best practices, you'll transform your HTML and multimedia to give your site more hurtle and less turtle. Let's also explore some common web page problems and trends that confront web performance engineers.

Common Web Page Problems

The size and complexity of the markup that you use in your web pages determine, for the most part, their initial display speed. Pages that are large and complex, especially those with nested tables and mispositioned CSS and Javascript files, delay the time it takes for useful content to display. Sleek and streamlined pages feel faster because of quicker feedback through progressive display. The idea is to streamline your markup using standards-based techniques and let your code get out of the way of your content.

CSS and Javascript File Placement

Positioning CSS in the top (head) and Javascript at the bottom (body) of your HTML enables progressive rendering. Mispositioned CSS or Javascript can delay the rendering of content in browsers.

As Steve Souders describes in his book High Performance Web Sites (O'Reilly), 80% of web page response time is in the content. Most of this time is spent dealing with the objects that make up a web page. As the number of objects per page increases beyond four, object overhead dominates total web page delay.

As you learned in the introduction to Part II, most popular web pages go well past this threshold, averaging more than 50 objects per page and more than 300 KB in total file size. Improperly coded, Ajax-enhanced pages can slow down interactivity, even after the page has loaded.

Clearly, there is room for improvement in the performance of the average website.

Oust Oodles of Objects

With the advent of Ajax, DHTML, and Web 2.0 mashups, some web pages have turned from simple HTML documents into full-blown interactive applications. With this increased complexity comes a cost: larger web pages. The number of external objects has grown accordingly as web pages have become more complex. Each additional object adds one more HTTP request and more uncertain delay.

Each object adds latency to your load time, increasing it an average of 0.25 seconds per object on dial-up and 40 ms on cable.¹ Overseas users suffer the most from object overage because long-distance connections require more hops and present more opportunities for data loss.

Untangle Tables

Tables are a poor substitute for CSS layout. Despite the widespread adoption of CSS, 62.6% of web pages still use tables for layout.² The average table depth has decreased by half since 2006, from nearly 3 to about 1.5.³ Complex nested tables can cause rendering delays with browsers because tangled tables must be parsed and rendered before your content displays.

Some database-driven sites create table-based content modules that are assembled on the fly into table-based templates. All of these nested tables will bog down browsers and overwhelm your content-to-code ratio. This reduces the potential search engine rankings of your web pages.

You can reduce the depth of nested tables by styling, labeling, and positioning content areas with CSS and using simpler skeleton tables for layout. You can then target content within labeled container cells with compound selectors such as:

td#main p{}

Or, you can use CSS entirely to position, style, and target content like this:

div#main ul{}

Covering all the intricacies of CSS layout is beyond the scope of this post; we encourage you to refer to some of the excellent books on the subject, including CSS Mastery by Andy Budd (friends of ED), and CSS Web Site Design by Eric Meyer (Peachpit Press).

Optimize Overweight Graphics

The average web page has more than 54% of its page weight in graphics.⁴ In fact, more than 60% of the pixels above the fold are used by graphics on the average web page.⁵

Unfortunately, many of the graphics on the Web are fat and unoptimized. As digital camera resolution has increased, the file size of digital originals has ballooned, and some online graphics exceed 1 MB. Trying to view such bloated graphics on a dial-up connection is like trying to get a camel to pass through the eye of a needle.

The cost of banner advertising

Most popular media and blog sites use image-heavy advertising to generate revenue, at a cost of about one-sixth more objects and one-third more latency.⁶ A survey of the top 1,300 Alexa sites found that 56% of these web pages contained ads or some form of "extraneous content."⁷ Blocking ads reduced the number of objects and bytes by 25% to 30%, resulting in a proportional reduction in latency.

We've analyzed web pages with 300 KB to 500 KB of banner ads. Without ad size policies in place, the total impact of advertising can become even more significant. If you use graphical ads, set file size criteria for the banner ads of your advertisers, criteria that are appropriate to banner dimensions.

The growth in the number and size of advertisements has caused significant delays for users. However, displaying ads also incurs the overhead of remote network hosting (in most cases) and additional logic to deliver ads to the screen (usually done with Javascript). Remote Javascript is the most inefficient ad delivery method, yet it is in widespread use because of its convenience. In "Step 1: Minimize HTTP Requests," we'll show how server-side includes can deliver ads to save HTTP requests. In "Step 10: Load Javascript Wisely," you'll learn how to make Javascript load asynchronously.

The Growth of Multimedia

The popularity of Flash and the likes of YouTube, Yahoo! Video, and MySpace have increased the use of multimedia on the Web. As broadband penetration has increased, videos have grown in size, bit rate, and duration (see the image below, "Growth in the duration of web videos").

In 1997, 90% of online videos were less than 45 seconds in length (see the image below, "Growth in the duration of web videos").⁸ In 2005, the median video was about 120 seconds long.⁹ By 2007, the median video was 192.6 seconds in duration.¹⁰ The median bit rate of web videos grew from 200 Kbps in 2005 to 328 Kbps on YouTube in 2007. So, by late 2007, the median video weighed in at more than 63 MB in file size.

Figure 6.1. Growth in the duration of web videos



The majority of multimedia traffic comes from files that are larger than 1 MB, but most requests come from files smaller than 1 MB. More than 87% of all streaming media is abandoned by users in the first 10 seconds, however, wasting up to 20% of server bandwidth.¹¹ Although only 3% of server responses are for videos, they account for 98.6% of the bytes transferred.¹² So, although videos account for a small percentage of requests, they make up the majority of the traffic on the Web.

Overall, for videos longer than 30 seconds, about 13% of home and 40% of business users experience quality degradation with their streaming media, caused by rebuffering, stream switching, and video cancellation. For sessions longer than 300 seconds, the results are even worse. In "Step 3: Optimize Multimedia," you will learn how to combat the growth of multimedia with specialized tools and techniques.

How to Optimize Your Web Page Speed

To optimize your web page speed, start by stripping out all inline style. Pare down your markup to pure HTML structure. Next, look at your page to see whether any elements can be created by more efficient means. You can often morph HTML structural elements with CSS to replicate table-based elements more efficiently.

What Are CSS Sprites?

Originally used by 2D video game programmers to save resources, sprites have been adapted for the Web using CSS. A CSS sprite is a grid of images merged into one composite image. This sprite is then set as a CSS background image for multiple classes, and individual cells are displayed using background positioning for each class. CSS sprites save HTTP requests, but you must use them with caution to ensure accessibility.

After your code has been stripped of style and refactored, convert that embedded style into rule-based CSS. To enable progressive display, position CSS files in the head and Javascript files at the end of your body code. Minimize the number of HTTP requests by combining files, and by converting graphical text to CSS text. Use CSS spacing, CSS sprites, image maps, and background colors to save requests. Optimize any remaining images and multimedia to the lowest acceptable quality and frame rates. Enable caching for persistent objects and distribute them over different servers to minimize latency. Finally, use HTTP compression to shave an average of 75% off XHTML, CSS, and Javascript file sizes.

Switch to Semantic Markup

The foundation of these techniques is a switch to web standards (XHTML 1.0 and CSS2 or 3). By converting old-style nonsemantic markup into semantic markup, you can more easily target noncontiguous elements with descendant selectors.

Artificial XHTML structure can crop up in web pages created manually and with some WYSIWYG programs. This "fake structure" uses the font tag or CSS to artificially simulate structural markup, such as <h1>, <dl>, or <ul>.¹³ One problem with fake structure is that it cannot be easily targeted with type or descendant selectors that are designed to point to structural elements.

High Performance Web Site Tips

The following tips are derived from the book High Performance Web Sites (O'Reilly) by Steve Souders:

• Make fewer HTTP requests to reduce object overhead.
  
• Use a content delivery network.
  
• Add an Expires header.
  
• Gzip/compress text components.
  
• Put stylesheets at the top in the head.
  
• Put scripts at the bottom of the body.
  
• Avoid CSS expressions which are CPU-intensive and can be evaluated frequently.
  
• Make Javascript and CSS files external.
  
• Reduce Domain Name System (DNS) lookups to reduce the overhead of DNS delay by splitting lookups between two to four unique hostnames.
  
• Minify Javascript.
  
• Avoid redirects which slow performance. It's better to CNAME or alias.
  
• Remove duplicate scripts to eliminate extra HTTP requests in Internet Explorer.
  
• Configure ETags for sites hosted on multiple servers. FileETag none in Apache removes Etags to avoid improper cache validation.
  
• Make Ajax cacheable and small to avoid unnecessary HTTP requests.

In addition, proper structural markup conveys helpful information to whoever is maintaining the site with headings, paragraphs, and list items. Semantic markup can save countless hours of work in site redesigns. Search engines look for structural markup to see what information is most important. Accessibility and cross-platform access through mobile devices is enhanced when you use structural markup. Screen readers key off structural waypoints and users tab through a page based on semantically meaningful markup. For all these reasons, you should avoid fake structure like the plague.

So, for example, this (adapted from a real web page):

<p style="color:red"><strong>Fake descriptive term</strong><br>

   <font size="2" color="black">Description of first term here, no
structure to target!</font><br>
<strong>Fake descriptive term 2</strong><br>
   <font size="2" color="black">Description of second term here, no
structure to target</font></p>...

becomes this, by abstracting the inline styles to a matching structural element:

<style type="text/css">

<!--
dl dt{font-weight:bold;color:red;}
dl dd{font-size:0.9em;color:#000;}
--></style></head><body>
<dl>
    <dt>Descriptive term 1</dt>
    <dd>Description 1 here, no problem targeting</dd>

    <dt>Descriptive term 2</dt>
    <dd>Description 2 here, styled by a single CSS rule </dd>
</dl>

Notice how clean the structural HTML code is when compared to the unstructured example.

The last code sample is easier to target with CSS using simple descendant selectors (dl dt and dl dd). The first nonsemantic sample forces the use of embedded styles. For more information about web standards, see http://www.webstandards.org and http://www.w3.org.

Use container cells for descendant selectors

If you plan your web page to use container divs from the start—#masthead, #content, #navigation, and #footer can be your major container divs—you can avoid the need to embed classes within structural elements. You can then target enclosed content with descendant selectors. For example, the following navigation menu can be targeted through the surrounding nav element:

<style type="text/css">

<!--
#nav ul, #nav ul li {list-style:none;}
#nav ul li {font-weight:bold;}
--></style>

Here's the HTML markup:

<div id="nav">
    <ul>
        <li>Burma</li>
        <li>Shave</li>

    </ul>
</div>

Now you can declare these styles for all of your navigation, content, and other areas without the need to embed classes within HTML elements. The idea is to strip your HTML down to its structure, group the content within labeled divs, and target this structure with CSS selectors, descendant or otherwise.

If all browsers were as well behaved as Opera, Firefox, and Safari, you could use "grouping" elements such as body and html to avoid embedding classes within container divs. Instead, we recommend using labeled container divs such as #nav, #content, and #footer. Use CSS IDs for these main container divs that are used only once per page and then use CSS classes for most everything else. Keep in mind that CSS IDs have stronger specificity than CSS classes.

[1] Chung, S. 2007. "The investigation and classifying the web traffic delay & Solution plans presentation." In ICACT2007 2 (February 12–14, 2007): 1158–1161.

[2] In a July 2007 random survey of 500 pages indexed by Binghamton University's Ryan Levering for this book, 62.6% of pages used the table tag and 85.1% used the div tag. Tables nested to an average maximum depth of 1.47, with an average number of 12.57 table tags per page. The average maximum HTML depth was 15.35, demonstrating how divs have replaced table nesting. The data for this web survey is available at http://www.websiteop...page/survey.xls.

[3] Levering, R., and M. Cutler. 2006. "The Portrait of a Common HTML Web Page." In DocEng '06 (Amsterdam, The Netherlands: October 10–13, 2006), 200. Tables nested to an average maximum depth of 2.95.

[4] According to Levering's 2007 survey, the average total image size was 118,683 bytes. The average total page size was 218,937 bytes, and 266,070 uncompressed. Thus, images make up at least 54.2% of the average web page.

[5] Levering and Cutler. "The Portrait of a Common HTML Web Page," 200. More than 60% of the area above the fold is used for graphics in the average web page.

[6] Krishnamurthy, B., and C. Wills. 2006. "Cat and Mouse: Content Delivery Tradeoffs in Web Access." In WWW 2006 (Edinburgh, Scotland: May 23–26, 2006), 337–346.

[7] Ibid., 346.

[8] Acharya, S., and B. Smith. 1998. "An Experiment to Characterize Videos Stored On the Web." In MMCN 1998 (San Jose, CA: January 1998), 166–178.

[9] Li, M. et al. 2005. "Characteristics of Streaming Media Stored on the Web." ACM Transactions on Internet Technology 5 (4): 601–626.

[10] Gill, P. et al. 2007. "YouTube Traffic Characterization: A View From the Edge." In IMC 2007 (San Diego: October 24–26, 2007), 15–28. About 24% of videos are interrupted because of poor performance or poor content quality.

[11] Guo, L. et al. 2005. "Analysis of Multimedia Workloads with Implications for Internet Streaming." In WWW 2005 (Chiba, Japan: May 10–14, 2005), 519–528.

[12] Gill, P. et al. "YouTube Traffic Characterization," 20.

[13] Levering's 2007 survey concluded that 32.8% used the font tag and only 58.5% used the h1 tag.