22 April 2009
Web page size and browser performance – why it still matters
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
- 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.
- 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.
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
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.