Performance Problems?

The somewhat recent (April 2010) announcement by Google that response time is going to be a factor in Search Engine Rankings means that Business Analysts in the Online space need to place added emphasis on performance Non-Functional Requirements. Previously, performance had predominantly been a visitor retention factor for websites, but now it has also become a factor in traffic generation.

In this post I’m going to describe some of the engineering aspects that can affect the performance of a website, knowledge that will be useful during elicitation and acceptance. I’m also going to provide a checklist that you can use to validate whether you’ve captured performance requirements in a “complete” fashion. The key thing to remember with Online is that server side performance is only one of a myriad of factors – all of which can affect end user response time.


How a web page is rendered

In simple terms, when a user opens a page on the Internet:

  • The browser looks up the domain name and works out the IP address of the web server it needs to talk to (this is called DNS resolution or DNS lookup);
  • The browser produces a message which is sent via the internet to the web server (this is called an HTTP request);
    • In larger solutions the request might hit something called a load balancer which directs requests to web servers in a cluster depending on how busy they are.
  • The web server receives the request and either: locates static resources; or, talks to software and database components to produce the dynamic resources; which comprise the webpage (e.g. HTML, CSS, JavaScript, images, media, etc.);
  • The web server produces a message which is sent via the internet to the browser (this is called the HTTP response)
  • The browser interprets the HTML, CSS and Javascript, acquires images and other media and renders a web page.
    • Sites that have heavy media requirements (e.g. sites with a lot of photography or video) may push media content to the “edge” of the network using a Content Delivery/Distribution Network (CDN) which means that the web server only needs to know the location of the content and that the content is delivered to the browser more quickly.
    • The web server or load balancer may also be configured to compress this content (using GZIP compression) to ensure faster delivery to more modern browsers.

As an analyst, it is important to understand that each of these steps may impact performance:

  • If the DNS records are configured sub-optimally then DNS lookup will add up to 2-3 seconds to the page response;
  • If server side software is developed sub-optimally then server performance can add significant time to the page response;
  • If the total page size is large (e.g. uncompressed whitespace, images, media) then network bandwidth and latency will add time to the response which will get worse depending on the end user’s network link;
  • If the HTML and CSS is not authored according to best practices and is not standards compliant (i.e. validated against the appropriate DOM) then the browser needs to make assumptions when it’s rendering the page which can add time to the response.

In a single provider environment (where a single vendor is delivering software, hardware and hosting) you may be able to simply specify end-to-end requirements but when you’re working with multiple vendors who are responsible for different aspects of the solution it’s advisable to take a more detailed response.


Web Optimisation Requirements Checklist

The following are some simple suggestions for ensuring that your performance requirements are complete:

Have you considered DNS performance as part of your overall rendering time?

Your software vendor should not be held accountable for the performance of your infrastructure configuration unless they’re providing a turn-key solution.
Do your performance requirements take into account to-premises delivery time?

Consider the bandwidth available to your users – regional users will likely be on much slower network links.  
Enforcing to-premises expectations against an agreed bandwidth helps to ensure that you’re getting optimised web pages.
[  ]
Have you included render time performance as a requirement and have you benchmarked it on a particular browser, O/S and hardware specification?

Render time is heavily influenced by end user hardware, O/S configuration, browser version, anti-virus software and other running processes.
[  ]
Have you documented requirements which enforce the adoption of HTML and CSS best practices (accessibility standards, graceful degradation, content – HTML vs layout – CSS)?

Not only will this mean that your website is accessible to the largest range of users, it will also help to ensure that it’s fast.
[  ]
Do your requirements include some variance in expectations?

Due to the complexity and unpredictable nature of all the elements above, it’s not reasonable to say that all pages must be rendered within 5 seconds.  For example, consider the 90th and 99th percentiles.
[  ]
Are your performance expectations reasonable?

Benchmark your performance requirements against similar websites.  If you’ve got an image heavy website you’re not going to perform like google.com.  Find similar websites, do some performance testing of your own and use those as a benchmark.
[  ]
Are your requirements of a high quality (e.g. SMART) and commercially sound?

Performance requirements are generally elicited to ensure that vendors or software providers deliver to expectations.  Take a moment to put your vendor hat on and ensure that your requirements will stand up to questioning.
[  ]

Other notes

There are a number of useful tools on the Internet for profiling performance in a complete manner. For further information I recommend you assess some of the following tools:

    • Google PageSpeed (hosted version of Google PageSpeed which provides graphical reporting)
    • YSlow for Firebug (a combination of a variety of tools)

It’s also worth mentioning that the earlier that you can capture performance requirements, the earlier the development and testing teams can start to integrate them into their deliverables. Performance engineering is really difficult and the earlier the team can focus on it, the better.


Leave a Reply

Your email address will not be published. Required fields are marked *