The link between page performance and conversion rates is well established. Users tend to become frustrated with pages that are slow to download and click away before the page will appear leading to a loss of customers.

As far back as 1999, Zona Research reported that 30% of web users would abandon a page if it took more than 8 seconds to load. Web developers had to be aware of an “eight second rule”, where the size of page content had to be carefully managed in order to avoid a significant drop-off in conversion rates.

In the late 1990s 56k modems were the mainstream connection speed so page size was a critical issue for developers. Web page development involved a constant process of ruthless optimisation - every file was stripped of comments and unnecessary space before moving it to a live environment and every image was squeezed down to the lowest possible page size.

The growth of broadband services since the late 1990s has allowed web developers the luxury of apparently unlimited bandwidth. This has allowed page optimisation to become a “lost art” among web developers.

Why page performance is still important

Despite the growth of broadband connections, page performance remains an important factor for several key reasons.

Firstly, user expectations have increased alongside connection speeds. What used to be an “eight second rule” is more like a few seconds today. In this respect, there is much less margin for error with page performance as users have become more impatient. Relatively minor performance bottlenecks can lead to an unexpected drop-off in conversion rates for those pages that are larger than they need to be.

Unnecessarily large pages can also eat into a site’s bandwidth allowance incurring extra running costs. On very busy websites small improvements to page size may not be noticeable to broadband users, but they can scale up to represent considerable savings in terms of bandwidth cost.

There is also an accessibility angle to page performance. The exact numbers of dial-up users are hard to define, but there remains a small group of users with dated equipment and dated internet connections. OfCom - the UK telecoms watchdog - reported in August 2008 that 58% of homes have taken up broadband services and that the rate of growth has slowed compared with previous years.

A great deal of effort has gone into establishing standards for ensuring that websites support assistive technologies, but the proportion of internet users still accessing the web via a modem and phone line may well be greater than those using screen readers. The internet should be available to all users, not just those with up-to-date internet connections.

How to improve page performance

Improving page performance is largely a matter of discipline - rediscovering the “lost art” of web page optimisation that was an essential developer skill in the late 1990s.

1. Be aware of your page weight

Page weight refers to the total size of all the files included in your page - including HTML markup, CSS stylesheets, JavaScript files and images. Page weight can add up quickly if it’s not explicitly kept in check and 300k is a reasonable maximum to aim for. You should be aggressive about optimising content - any small savings you can make will be of benefit.

• Minimise the size of CSS and JavaScript files on a production environment by removing any unnecessary characters such as comments and white space. Tools such as Yahoo’s YUI Compressor can help here.
• Ensure that all your image files are as small as possible, using the maximum possible compression that doesn’t compromise image quality

2. Minimise the number of separate HTTP requests

Overall size isn’t the only factor here - the number of individual files involved in a page is also significant. The majority of end-user response time is spent downloading the various components of a page and reducing the number of individual files to download can help performance.

• Consider combining CSS and JavaScript files into a single file on a production environment rather than distributing them as a large number of individual files. Although working on individual files can be more convenient in the development context, deploying a large number of CSS and JavaScript files does have a detrimental affect on performance.
• Reduce the number of image requests by using CSS sprites for background images. This is a technique where individual images are combined into a single image and their display on the page is controlled using the CSS styles background-image and background-position.

3. CSS at the top, JavaScript at the bottom

Putting stylesheets in the header section of an HTML document makes a page appear to load faster as it allows a page to render progressively. Although this does not help download speed it does provide the user with more visual feedback as the pages loads. It’s also worth pointing out that the HTML 4.01 specification states that <link> tags should only be included in the header section.

Scripts on the other hand should be placed at the bottom of a page where possible as they tend to cause a download bottleneck. The HTTP/1.1 specification suggests that browsers do not download more than two components in parallel - if a script is downloading it will prevent any other files from downloading. Note that it is not always practical to put scripts at the bottom of the page, particularly if the page relies on code that has to be executed on the page’s OnLoad event.

4. Optimise the HTML

HTML code should also be optimised ruthlessly. Any unnecessary tags should be removed and the page’s DOM should be as simple as possible. Unnecessary tags will not only increase download time but also slow down JavaScript processing on the page as the code will have more nodes to navigate through.

Remove any duplicated CSS and JavaScript file includes - these kinds of duplicates are more common than you might think.

5. Using ASP.NET? Then minimise the use of view state

ASP.NET’s view state is a useful mechanism for maintaining page state information between requests, but it is can leave a large footprint on a page. It’s also switched on by default, so always make sure that you take the time to minimise the impact of view state on pages, either by switching it off at the page level or on the control level.

Filed under ASP.NET.