Measuring Site Performance (Part 2)

In this column we will continue with our examination of website metrics. Last column introduced the idea of performance metrics and the basics of what to measure. In this column I would like to go a little further into discussing the implications of those metrics.

From a business perspective, performance metrics are not an exercise in technical esoterics, but rather an attempt to gauge your site’s performance as it affects users of your website. For some firms, performance is mission critical. If, for example, your site includes ecommerce functionality, it is necessary to maintain an always up, always accessible website. A slow site or downtime translates into lost sales. Similarly, though of perhaps a less critical nature, if your site offers online customer service the performance of those customer facing systems is critical to maintaining customer satisfaction. But the list of those affected by poor site performance doesn’t stop there; poor performance will have a negative effect on any website. Web users tend to be impatient, and as the cliché goes, your competition is only a click away.

I am sometimes amazed by companies who tolerate under-performing web properties. Would you mail to your customers a brochure that they cannot read? Would you air a television commercial that contains only half a picture and garbled sound? Obviously not, but companies still produce similarly flawed websites — and then discuss cynically how the Web doesn’t deliver on its promises.

The web is not the problem, the sites are. While we here in Thailand must suffer on in a bandwidth desert, it doesn’t mean that Internet connections as a whole are problematic. Moreover, while we cannot do anything about our bandwidth situation, we can make sure that the sites we produce perform well, regardless of the users’ environmental constraints. We must strive for world class standards and to the extent possible offset the peculiarities of the local market with smart design.

Last week we talked about key indicators that would allow you to assess your site’s performance. I mentioned:

* system uptime
* server response times
* page download speeds
* server errors
* failed hits
* form failures
* effective bandwidth per user

What do those numbers tell you?

System Uptime tells you the percentage of time the server was available and delivering web pages to site visitors.  Down time is what we want to avoid.  Down time is an inescapable reality as servers require re-starts and re-boots due to a variety of factors, including perfectly normal operations like software upgrades. What we need to avoid is excessive frequency and long duration of any one event. This data is generally supplied to you as part of your hosting support package. To improve service in this area, look for a web host partner who gives you an uptime guarantee.  If this is mission critical to your firm, build redundancy in drives (e.g., RAID 5), in processors (multi-processor machines), and in machines (clustering).

Server Response Times tell you how quickly the server responded to a request from a site visitor. Every time a site visitor clicks on a link a request is made to the server. We want the server to respond quickly, regardless of load.  This statistic is commonly mined from stress tests in order to determine how response time varies under load. To improve this metric you must look a variety of items, including whether your code set is optimized to deliver the fewest requests possible and to retrieve the data quickly (the latter is often a database optimization issue). Another key factor is the hardware itself — is it up to the job?

Page Download Speeds will tell you, on average, how long it takes for a page to load completely. This is a metric you can benchmark yourself (click and count!) but remember that your analysis will be skewed by your local Internet connection and the browser you use. To get accurate metrics, sample from a variety of locations. The key factors here are the size of the page and the performance of dynamic content (database-driven content) on the page, if any.

Server Errors, Failed Hits and Form Errors are your key error indicators. This data can be found in your log files (or your WebTrends report, as discussed previously). Note that all errors are not created equal and that means you need to look at more than a raw count; you need also to look at the type of error generated. The type of error will help you identify server performance problems.

Form Errors data is critical as this indicates how the forms on your site are performing.  A form that fails a disproportionate percentage of the time can indicate problems with either your code on the form or with some problem in your system architecture.

The last factor mentioned, Effective Bandwidth Per User, tells you how much bandwidth is available to each site visitor and is a good indicator of whether your current hosting set up provides adequate bandwidth to support the site’s traffic. This data can be found by running a server stress test. If you find your bandwidth plateaus at unacceptably low levels, you should be looking at a bandwidth package that gives you guarantees of peak usage availability (bandwidth on demand).

That’s it for this week. Next article we move on to Popularity Metrics.

  • view Part 1 of this Artilce
  • view Part 3 of this Article