During an implementation call with a client few weeks ago, I was asked “What metrics should we optimize for?” It’s a question I’m asked regularly, so I decided to do some extra research into the subject and resolve it once and for all.

From my experience working with customers to understand their performance problems, proven solutions I’ve seen work, and some help from the amazing #webperf hivemind on Twitter,  I came up with some solid answers for both this customer and the readers of Rigor’s blog. Read on below to learn about key web performance metrics for landing pages and marketing sites at large.


A Modern Problem

The origin of my customer’s problem is both a blessing and a curse for us web performance geeks. Given the multitude of web performance metrics and different ways to collect the necessary data, it can be hard for someone relatively new to the flock to know where to start.

For instance, some web performance metrics are more esoteric than others. My favorite example is browser CPU usage. This is a great thing to look at if you are literally looking for milliseconds to shave off, or if you know that you’re moving a ton of the rendering away from your own servers and toward the client side. But for the web citizens who still aren’t sure whether to use jpeg or png, a metric as exacting as CPU usage may be a bit advanced. Though it’s definitely something we should all aspire to.

And this gives us a cogent example of where to start for those just beginning their web performance journey. Different types of content (HTML, JavaScript, images, etc) have substantially different impacts on performance. You need to understand and optimize these areas before you move on to more complicated topics.


Can the Web Performance Community Just Pick One?

Simple Answer: No.

With the oodles of research that companies like SOASTA, Google, Akamai, and others have done on the topic, it does seem like it would be possible to identify just a handful of essential web performance metrics. It isn’t so easy to do this because, in reality, we do keep coming up with new aspects of performance to measure. However, these don’t necessarily negate any of the older metrics. Many classic web performance metrics such as DOMload and time to first byte are still relevant, even with more nuanced metrics like Time to Interactive (TTI). Even at Rigor we trend and alert on 23 different performance metrics in order to support the vastly different use cases from mid-market to enterprise customers.

If there isn’t one metric to rule them all, then the question becomes–why so many metrics? Some metrics are tailored for a very specific use case so they may not correlates with others. Below is a great example using “time to first byte,” “Visually Complete,” and “Image Count” (one of Rigor’s custom metrics).

A pretty clear correlation is evident even from a glance. The green line (Image Count) and the black line (Visually Complete) are nearly parallel to each other. Given this brief data set, it is probably safe to begin drawing conclusions about the two while ignoring time to first byte (blue line).

However, this doesn’t mean that time to first byte is irrelevant overall.  Time to first byte remains a valuable metric to understand server connection issues like the one shown in this waterfall chart:

This is the waterfall of just one page in a user flow that visits five different pages in the course of the flow. This one particular page has a history of wrecking the load time of the total flow, so we know it is one which we need to improve.

Looking at a comparison of all the web pages from the user flow (see Below), we can see the clear value of trending time to first byte for this apparently unstable connection. (Hint, the blue line represents the waterfall above, where the black line represents the page before this one in the user flow).

Knowing that the time it takes to receive any response from the web server is being measured in seconds not milliseconds, we probably can start here as opposed to worrying about image counts the way we were in the previous example.


How Can I Make Sense of Web Performance Metrics?

There are many metrics that are important to track, and lots of good reasons why you should choose one over another.

However, when it comes to trending and improving your performance, the metrics that matter most are the ones you can correlate with your business metrics.

Let’s talk about a familiar one –Bounce Rate– as an example. Philip Tellis, the creator of the RUM project Boomerang, has honed in on what he calls LD25 and LD50. These stand for “lethal dose” 25 and 50 which means the percentage of users who bounce for a given web performance timing. Based on his research, optimizing performance to get page load time below LD25 for Bounce Rate is key.

Once you have determined the most meaningful business metric, start to work backwards to find the performance metrics that get you there.

For example: If Bounce Rate is my metric, and LD25 is a Visually Complete time of 6 seconds, what do I need to get my image count down to in order to hit all of the above goals? Rinse and repeat for each business metric, their corresponding LD25’s and performance metrics.

Maybe you have more advanced web performance goals, and need help identifying what metrics are most important. If that’s the case, consider reaching out to a member of our team to learn about how we can customize a performance plan to meet your needs.

Suggested Blog Posts

Mobile Banking a Top Priority for Financials

As mobile devices continue to play a more prominent role in our 21st century society, their usefulness has spread beyond the casual activities of technological enthusiasts. According to research conducted by FUNDtech, a rapidly growing number of ba...

Read More

The Perception Gap for Poor Web Performance

E-commerce is a growing source of revenue for many companies and businesses, as it continues to capture market-share from brick-and-mortar stores over recent years. However, many businesses are not prepared for this growth of online business becau...

Read More

Measuring Cross-Browser Performance

In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design for an...

Read More