An Introductory Course in Web Performance Metrics

web-performance-metrics-101

Slow response time has been the most common complaint of site users since the inception of the Web. Just when we thought broadband and quad core processors would solve all our problems, mobile devices and Wi-Fi hotspots set us back again. The struggle against latency remains an ongoing battle, but the first step towards a faster Web begins with accurately measuring and optimizing the factors that make up response time and page load time.

In 2006, Amazon reported that for every 100ms improvement in response time, they received a 1% increase in revenue. In 2008, Shopzilla reduced page load times from 7 seconds to 2 seconds and saw a 7% – 12% increase in conversion rate. In 2010 Mozilla shaved 2.2 seconds off its landing pages and increased download conversions by 15.4% — resulting in an additional 60 million downloads. While these stats clearly quantify the value of optimization, it doesn’t tell us how fast is fast enough. Clearly there must be diminishing returns in optimizing for response and page load time. We’ll, get to that, but the first question really needs to be — what exactly do we mean when we refer to response time?

Technically, response time is the time it takes for a user to send a command (for example, a page request) and the browser to finish loading the related HTML. Simple enough, but when you consider how a modern page is designed, with so many additional objects, response time doesn’t tell you very much about the user’s experience.

Response Time

Response time consists of the following components:

  • DNS resolution time
  • TCP connection time
  • HTTP redirect time
  • Time to first byte
  • HTML content time
  • Full page object load time

Finding the exact cause of a slowdown requires knowing how these components operate — both individually and together.

Page Load Time and User Experience

Now that we’ve explored each component of response time, you should have a better understanding of how to use these metrics to identify the source of your problem (if you have one) — but the question of how to measure and optimize the user experience still remains. While these network side metrics can tell you where to look if you have a problem, they don’t necessarily uncover the affect of the problem on your users.

When talking about speed improvements that translate into revenue, we’re talking about user perception — how users are actually experiencing your website and applications. While these backend metrics can provide insight around specific technical problems that may or may not be affecting overall page load and response times, there is no direct connection between their measurements and the user’s experience.

While this continues to be an evolving area for performance metrics there are several newer metrics that you should be leveraging in order to monitor your users’ perceptions of performance and overall experience.

These include:

  • Page Load Time
  • DOM Load Time
  • First paint Time
  • Above-The-Fold Time

Technically, Page Load Time and DOM Load Time are browser timings, not user timings, but they help set the stage for what the user perceives.

If you want to take a deep dive into the definitions of each of these individual metrics and learn more about how they can influence your site’s user experience, feel free to download our free eBook by clicking the link below:

Web Performance Metrics 101 eBook

See also:

Comments

  1. Some of the numbers are not consistent – for example, Amazon claims that for every 0.1 second improvement, they have 1% more revenue. Shopzilla, however, had a 5 second improvement, which means 50% more revenue according to Amazon, but only got about 12% (at best). Now I know that we can’t really compare these as an apple for apple, but the difference is substantial.

    PS: Page speed is also a contributing factor to the rankings of the page in the SEs (especially Google).

Speak Your Mind

*