Fast Web Pages

by Craig Mazur - Copyright © 2004 - all rights reserved

January 2, 2004

How many times have you visited a Web site and found yourself abandoning the site because the pages are slow to load? What was your initial impression of that site? Chances are that you will not consider visiting the site again if your first impression is poor or you think the site may have technical problems.

When contemplating whether or not your Web pages are downloading and displaying (rendering) quickly enough to retain your visitors, consider this:

Page rendering time is the first impression a user gets when visiting a site.
Page design is the second impression.
Content is the third impression.

... you only have about ten seconds to impress your visitors.

When someone immediately abandons your Web site because it is slow, you never give them a chance to form a second or third impression. You may have the most beautiful Web site ever created, or the most useful content. Neither holds any value if the user is frustrated before they get to see either. Numerous studies have shown that users begin to get frustrated with slow Web pages in ten seconds or less. The bottom line is that you only have about ten seconds to impress your visitors.

So how do I make my Web site run faster?

There are many factors that affect how fast a Web page loads and renders in a browser. Most problem areas are actually fairly easy to find and correct.

#1 - Make sure your Web server is not part of the problem

The first thing you need to do is to make sure that you have a reasonable amount of trust in your Web server environment. Web servers are very efficient at delivering Web pages and images to users, but every server has a finite amount of resources to work with. Factors such as CPU speed, memory and the number of Web sites on a server can dramatically affect it's speed and efficiency.

Some hosting companies literally place hundreds of Web sites on a single personal computer configured as a Web server. When this happens, a site might seem to run reasonably fast during slow usage times of the day, but will slow down considerably at peak times because the PC can only handle a limited number of Web page requests at any given moment. Too many sites competing simultaneously for a limited amount of server resources is a recipe for poor performance. If you are using a free or a $4.95 per month hosting service, the chances increase dramatically that your site is one of too many on a server. Ask your hosting company how many Web sites they put on a server and ask about server specifications. Many hosting companies will not provide this information. If you suspect that the server is part of the problem, you may want to consider switching to another hosting company or upgrading to a plan where performance is monitored and guaranteed.

Many e-commerce sites and sites with high volumes of user traffic opt to run on a dedicated server. This means that there is only one Web site running on the server, so it does not compete with other sites for resources. Dedicated hosting tends to be expensive and beyond the budget of most small Web sites, so for most sites other options need to be considered.

#2 - Web page design factors that affect speed

The single most important factor that you can control is page weight.

The single most important factor that you can control is page weight. The page weight is the total size in bytes for all code, content, images and objects that must be downloaded from a Web server to the browser on the user's PC. The larger the page weight, the longer it will take to download and display. Contrary to a popular misconception, you are not actually connected to a Web server while you are viewing a Web page. You only connect to a Web server for the few seconds it takes to download a Web page's code, content, images and objects. From that point on, the Web page runs in your browser.

There are two elements at play:

Delivery - the amount of time it takes to deliver the code and images from the server to the user's PC across the Internet
Display - the amount of time it takes to render the Web page in the user's browser

Delivery time is directly related to the efficiency of the server, the connection speed of the user and the size of the files that need to be transferred. For obvious reasons, high-speed Internet connections are much faster than dial-up connections, but the overwhelming majority of residential Internet users are still using slow dial-up connections. The reality is that you have no control over a user's connection speed, but it is nonetheless an important factor. If you want your site to appeal to the large number of users with slow connections, you need to remember that the smaller the combined size of the code, content, images and objects that needs to be transferred, the faster the page can be delivered.

The display, or rendering of the page, is related to the speed of the user's PC, the amount of code, content, images and object to be rendered (page weight) and the efficiency of the code. As a Web designer or developer, you only have control over the page weight and the efficiency of the code.

Controlling page weight

In order for a Web page to be delivered and rendered in ten seconds or less over an efficient dial-up connection you must strive to keep the page weight below 60,000 bytes (60 kilobytes or 60kb). 30,000 bytes is an even better target. The fact is that you cannot deliver a fast page to a dial-up user if you have 100kb in images and another 50kb in HTML and JavaScript code.

The first thing to look at is the images. The number one problem with most slow Web sites is excessive images and/or bloated image file sizes due to lack of optimization. Limit the number of images on each page to the absolute minimum required. Don't use an image if you can use a background color using HTML or CSS (Cascading Style Sheets). Make sure your images are optimized (files sizes reduced as much as is possible without degrading the quality) using one of the many popular image editors. Recognize that images containing primarily solids and lines can probably be made smaller and more efficient as .GIF images, while photographs can likely be made smaller as .JPG images.

You will need to learn HTML, JavaScript and CSS to fully optimize Web page code. You can partially optimize HTML code if you use WYSIWYG (What You See Is What You Get) development tools such as Microsoft FrontPage, Adobe GoLive or Macromedia Dreamweaver if you understand the important factors as you design a page, but in order to fully optimize a page, you will have to learn the languages. Fortunately, these languages are relatively easy to learn, but are beyond the scope of this article. If you do understand HTML, JavaScript and CSS, and you use one of the many WYSIWYG tools to design your Web pages, make sure you do a thorough code review for each page and eliminate all of the garbage most of these tools leave in the code.

Recognize that text is smaller and loads faster than images. Never use text in an image to convey a message unless it is the only way to do so. Slow Web pages are typically loaded with images containing text. In addition to adding weight to a Web page, they put your site at a disadvantage with search engines because very few can read text in images.

Speeding up the rendering time

Don't nest tables (tables within tables) unless you have to. Nesting tables slows rendering because it take longer for a browser to construct nested tables and very complex tables. The more tables you nest or the more complex your table designs, the more time it will take to render. If you use tables for layout, try to keep the design as simple as is possible. Have you ever seen a Web page flash or jump or re-arrange elements as it begins to render a page? This is due to something in the HTML code that causes the browser to re-evaluate and re-render the page.

Don't build a page using a single table. At a minimum, use separate tables for the header, the body and the footer. This doesn't necessarily lessen your page weight, but it will give a user the impression that things are loading faster as the page begins to render from the top down. When a page is rendered using a single table, the entire table must be constructed within the browser. When a page is broken up into separate tables, each table renders separately, giving a user the perception that the page is loading faster.

Declare all image dimensions in your code. Adding "width=" and "height=" attributes to your image tags may add a small amount of code, but can improve page rendering because these attributes act as a placeholder for images. Images are usually downloaded last because images need to be requested through the HTML script. If image dimensions are declared in the HTML code, the images slip right into their placeholders without forcing the browser to resize and re-render tables.

Reducing the amount of code on a page

This is the part that requires knowledge of HTML and the use of an HTML editor. You need to adopt a philosophy that says every byte matters. This means that every byte of code that can be eliminated from a Web page script will slightly lessen the time it takes to download and render a page. Granted, the time required to download and render a byte of code may seem extremely small, but cumulatively it has a noticeable effect. Here are some of the coding issues to focus on:

Do not create ladders or stairways in your code. Every tab and space is a byte. When you stagger your script code to make it more readable, you are wasting a large number of bytes. The more code you have in your script, the more bytes you will waste. Even though six spaces in a row only displays as a single space on a Web page, you still have to download six spaces. One method that works is to avoid indenting your table tags in your HTML editor or use only one or two spaces to indent the table cell contents in your scripts. If you view the code for this page, you will see what I mean.

Don't get excessive with HTML comment statements. If you can eliminate the use of comments in your code, you are much better off. Even though comment statements do not display, they must be downloaded with other code and parsed by the browser.

For a standard grid-type table layout, only declare cell widths in the top row. A browser starts to render a table from the top row down. Once it knows widths for each of the top cells, the remaining cells follow the pattern.

Move your CSS (Cascading Style Sheets) to a common external file that defines all the pages in your site. External style sheets tend to be cached by most browsers and will lessen download and delivery times. CSS can also dramatically reduce the amount of page weight. The only downside to using CSS is that some CSS rules are not recognized by Netscape 4 and other older browsers. You do need to be aware of which browsers your visitors use and make sure you test the site using those browsers.

Move common JavaScript code to an external file. This will also be cached by most browsers. JavaScript code used for rollers and other interactions can easily be made universal and applicable for all pages within a site.

#3 - Other tips to consider, particularly if your server is slow or loaded with Web sites

Don't use Server Side Includes if your site is small. If you use Server Side Includes (SSI), you know what this is. It is a technique available on most servers that allows you to merge segments of code into a single HTML page. SSI can save a great deal of time if your site is large, but they slow down the delivery of a page because multiple scripts must be combined before the server sends the Web page to the user. Too many includes on a page will have a noticeably negative impact on Web page delivery.

Don't use a dynamic Web page design if a static HTML design will work. Dynamic sites are a necessity when user interaction with a database or the server is required. But if the resources available on your Web server are already strained, the use of dynamic pages just compounds the problem.

There are numerous other issues that can negatively impact the speed of your Web pages. This article covers most of the common issues that affect most Web sites. The easiest way to combat the problem is to adopt the "every byte matters" philosophy and apply it to every Web page you design or maintain.