www.cryer.co.uk
Brian Cryer's Web Resources

Tips on designing a page for faster download

It is widely accepted that if a page takes more than 10 seconds to download then the user is likely to give up waiting and look elsewhere.

Is this strictly true? Surprisingly No. What is important is that within 10 seconds (or there abouts) the browser should have displayed meaningful useful information. Provided the user has a screen full of useful information then in most cases it does not matter if it takes a bit longer for the rest of the page to finish loading.

Why 10 seconds? Apparently this is about the limit for keeping most people's attention focused while waiting for information to load.

The purpose of this page is to set out a number of tips on how to improve the download time or how to get the impression of reduced download times.

The tips:

If you have any tips that you would like to contribute to this section then please e-mail feedback@cryer.co.uk.

Keep it small

It may be obvious but the larger your file the longer it will take to download. Therefore try to avoid anything that will cause the file to bloat. (But don't be tempted to skimp on the content of your site, after all that is what your visitors are coming to see.)

The editor that you use to generate your html will have some influence on the size of the file. Try to avoid Microsoft Word as your html editor because in my experience it generates very bloated files.

Keep it small: Use styles in preference to fonts

In classical html the only way to select which font to use was with the '<font ...> ... </font>' HTML tags. Style sheets are a more recent alternative to the '<font>' tag. Some editors (such as Microsoft's FrontPage Express) do not directly support the use of style sheets and older browsers will not recognise them and will therefore ignore them. Styles sheets do however offer significant advantages over using the font tag.

If the dominant font for a page is something other than the browser default then using a style sheet to change the default font is normally much more efficient on space than using the '<font>' tag. This is simply because the style sheet only needs to be defined once (at the top of the HTML file) whereas the '<font>' tag will need to be included in multiple places. Thus the use of a style sheet can reduce the overall size of the HTML file and thus reduce download times.

Below is a summary of how to define a style sheet to specify the font to use for a page.

The style definition, like classic html, is defined within <style> and </style> tags. The style sheet must be defined within the <head> of the file. The format of each line within the style sheet is:

selector {property: value}

To change the font used for the text of a file simply use:

<style>
<!--
BODY {font-family: Arial}
-->
</style>

This will change the default font to Arial. If your editor does not support style sheets then it will render the page using its default font (typically Times New Roman) but the page will appear in a browser (that supports style sheets) using Arial.

For more details on style sheets take a look at the excellent article at www.jalfrezi.com/styles.htm.

Images reduce effective bandwidth

There is no denying that images (pictures, backgrounds etc) can make a web site look much more interesting. The disadvantages associated with images is that they can take a noticeable time to download and they reduce the effective bandwidth.

Most visitors will probably wait for an image to download if it is something they want to see or if the image is merely for decoration (as most are) then a delay while they download will not put a visitor off. The thing to remember is that in the majority of cases it simply doesn't matter that images may take a while to download.

What does matter is the reduction in bandwidth while the image or images download. Bandwidth is the amount of data that your visitor can download at once. Typically for most surfers this is limited by the speed of their modem (a 56kbs modem can download at roughly 5K a second). If your site has images then the bandwidth will be shared between them. This is likely to be a problem if the html portion of your page is still being downloaded along side the images, because then it will slow the availability of the text portion of your site and it is typically the text portion that contains the information that visitors want to read.

Consider, a 56kbs modem can download at roughly 5K a second. However if your page contains a graphic background then the bandwidth will be split between the background graphic and the rest of the html, so the available download rate for each falls to 2.5K a second. Add to this if the page contains say three graphics at the top then the effective download rate falls further to just 1K a second. A 10k html file would then take 10 seconds to download not the 2 seconds that you might have expected.

Actually the situation is not as bad as this. Firstly there is some latency in the system. When the browser requests a file to download (in this case an image) there will be a small delay before the file starts to download. Secondly once the browser has loaded your page it should have any images contained in its cache, so hopefully when the visitor moves around your site most of the images will be fetched from the browser cache and not downloaded over the net.

If you perceive this to be a problem on some pages of your site then it is possible to delay loading of images until after the text portion of the page has loaded. The article 'How to dynamically load any html file component' covers how to do this - but for most pages it probably isn't worth the effort.

Avoid (large) tables - they are not displayed until completely loaded

Within HTML tables are very versatile, they can be used both in the traditional style to hold tabulated data or they can be used to position other elements on a page. Many pages uses tables to provide the basic framework for the page, using them to position both text and graphics.

The disadvantage of using tables is that a browser will not render (i.e. display) the table until all of the HTML elements of the table have been loaded, i.e. nothing within the table will be visible until the end of table HTML marker (</table>) has been processed by the browser. This is certainly true of both Netscape and Microsoft browsers. Thus if for example a table is used to position all the elements on a page then a surfer will be presented with a blank page until the end of the table was processed at which point everything will seem to appear at once. It is important to note that elements such as images will not delay the rendering of the table (other than the effect of reducing bandwidth) because these are loaded independently.

For small tables this is probably not an issue, but where they are used to layout a page the effect can lead to the page appearing to take an age to load.

So, what can be done? Consider whether a large table can be broken up into a number of smaller ones or whether some sections in a table need to be in the table at all. For example, consider the following fictitious page that uses a single table to control its layout:

graphic title graphic
page text
graphic advert graphic

This layout could be changed instead to:

graphic title graphic

page text

graphic advert graphic

The main difference between these two layouts is that in the case of the second, the browser will display the text as it becomes available. The header graphics and title will appear first, then the page text and finally the footer graphics. The total time required to display the two pages should be equal, but the second will appear to load much faster because information starts to be displayed that much sooner.

JavaScript and Style sheets - why external files can be bad

Any external file that the browser has to load synchronously (i.e. the file must be completely loaded before the browser can process the rest of the html file) is bad for performance. This applies both to external style sheets and to external JavaScript files.

Why separate style sheet files can be bad

It is becoming increasingly popular for pages to link to a separate style sheet file. This has the advantage that the same set of styles can be applied consistently to numerous pages.

From a performance point of view the disadvantage of this approach is that it is an extra file to load AND the browser will not render any of the page contents until the style sheet has been loaded. Given that most style sheets tend to be quite small (i.e. less than 1K), latency (i.e. the time between the browser requesting the file and it starting to arrive) is likely to be the only problem. Even so, this can quite easily add half a second to the download time - and this cost is incurred before anything is displayed by the browser.

Given that browsers will then typically cache the style sheet, subsequent pages on your web site that are visited should not incur the same penalty.

Why external JavaScript files can be bad

The same problem with style sheets also applies to JavaScript files. The exception is that whereas style sheets are included at the top of a file, JavaScript files can be included at any point in the file. The problem with performance only comes where the JavaScript is contained in a separate file, in-line JavaScript does not have the same problem.

Things to consider to improve the rendering of files containing JavaScript:

© Copyright 2004-2024, A B Cryer, All rights reserved.