Top Web Performance Metrics to Track

Top Web Performance Metrics to Track

Web performance monitoring is the practice of measuring metrics to assess how quickly a website or application is presented to an end user. Metric data is usually gathered via two main types of performance monitoring: active synthetic monitoring and passive real-user monitoring (“RUM”). A web performance monitoring tool takes raw metric data from your website or web applications, collates it, and presents it in various ways so performance issues can be analyzed and addressed quickly.

Most end-user response time occurs on the front end, so website performance monitoring is focused there. This contrasts with Application Performance Monitoring (APM), which traces a transaction’s performance across its back-end services.

Let’s take a closer look at web performance metrics and analytics.

• Metrics: Identify the web performance metric data to be measured
• Analysis: Apply data analysis to transform the metric data into information

Web performance metrics

Web performance metrics are generally discussed as web/IT metrics. The technology stack and architecture used to present a site or application to an end user will provide efficacy support for determining which metrics are most important for that specific use case. Web performance metrics typically include page load times, DNS lookup times, server response times, file sizes, and other metrics. When discussed as part of a business use case, such as web performance optimization, the most relevant metrics may include shopping cart size, conversion rates, time on page, and number of page views. Here are the top ten web performance metrics to measure when focusing your overall web optimization efforts.

Top web performance metrics

• DNS Time (or DNS Lookup Time): The amount of time required to resolve the domain name to an IP address. Every request starts in this way.
• Connection Time: The time required to establish the TCP connection with the IP address of the resolved domain name (the connection process is also known as the TCP handshake).
• SSL Handshake Time: The amount of time taken to establish the SSL handshake with the primary URL.
• Wait Time to First Byte (TTFB): The length of time between a client making an HTTP request and when the client receives the first byte of the request’s response.
• Response Time: The duration of the load time from when a client receives the first byte of the response to when the client receives the last byte of the response.
• First Contentful Paint (FCP): FCP measures the time it takes for the browser to render the first contentful paint from the document object model (DOM). This is an important metric because it provides the user with the first feedback on how the page is loading.
• Largest Contentful Paint (LCP): LCP is a Google Core Web Vitals metric that measures when the largest content element on a page becomes visible.
• First Input Delay (FID): FID measures load responsiveness by assessing the time from when a user first interacts with a page to when the browser can begin processing responses to that interaction.
• Total Downloaded Bytes (or Page Size): The total sum of downloaded bytes for all files included on the webpage. This can also be thought of as the total size of the data transferred between the server(s) and the client.
• Document Complete Time: The point in time when the browser’s onload event fires. This is generally when all static page content has fully loaded.
• Fully Loaded Time: The time it takes for the client to fully render any and all requests; it measures from the start of navigation to the last byte of the last received request, including any lazy-loaded, post-document complete requests.

Web performance metrics typically include page load times, DNS lookup times, server response times, file sizes, and others. When discussed as part of a business use case, such as web performance optimization, the most relevant metrics may include shopping cart size, conversion rates, time on page, and number of page views.

Web performance analytics

Regardless of which web performance metrics you observe and collect, analyzing the data they provide consists of two key components:

1. Trending over time: Use line charts with a designated calculation (e.g., arithmetic mean, average, or median) to see how web performance is trending over time.
2. Web performance long tails versus the average: use frequency histograms or cumulative distribution functions (CDFs) to analyze transactions that take much longer than average to complete, leading to user dissatisfaction, and that are difficult to isolate without sophisticated tooling. For long tail analysis, consider this “worst, better, best” reference:
   • line chart: worst for long tail analysis
   • frequency histogram: better for long tail analysis
   • cumulative distribution function (“CDF”): best for long tail analysis

Trending over time

When trending web performance data over time, RUM data typically follows a 24-hour end-user “wake up and go to sleep” pattern because it tracks real user traffic and “follows the sun”. Synthetic data, by contrast, will appear as a smoother line because the conditions of the emulated agents do not change over each 24-hour period. There may be times when either the synthetic dataset or the RUM dataset trends in a different direction. Therefore, it is important to use both Synthetic and RUM measurement types in your web performance monitoring program.

When trending web performance data over time, consider using one of two data aggregation calculations:

1. Arithmetic Mean Average: the mean average is the sum of numbers divided by the count of the numbers. When compared to the median, it is computationally inexpensive to calculate; however, it is more subject to skew from outliers.
2. Median: the middle number in a series of numbers. When compared to the average, it is computationally expensive to calculate, but it’s less subject to skew from outliers.

Here’s the above RUM data using both the average and median values:

Web performance long tails

When analyzing web performance data, it is important to view it as a composite to gain a holistic view of how end users experience your site. There are two core questions to ask:

1. What is the “average” performance for my end users? In other words, what type of performance are most end users experiencing?
2. What is the “long tail” performance for my end users? In other words, what proportion of users are having a negative performance experience?

The long tail is important to consider alongside the average performance time. One way to consider the long tail is to see it as a useful way to gauge the percentage of users having a bad experience, rather than having to guess. Rather than representing only a subset of users, the long tail is a gradient of user experiences. Not unlike considering the distribution of wealth in the world, long-tail analysis helps determine which portion of users would benefit from your precious web optimization efforts.

There are two important visuals that can help with your analysis:

1. The frequency histogram: This type of histogram is divided into buckets or ranges and shows how often web performance data occurs in those ranges. Compared with the cumulative distribution function, it is computationally inexpensive to calculate; however, it does not do as good a job of highlighting the long tail.
2. The cumulative distribution function (CDF): This shows the relative percentiles of web performance data and is an exceptionally powerful visual. Compared with the frequency histogram, it is computationally expensive to calculate, but it does the best job of highlighting the long tail.

Web performance frequency histogram

In the above histogram, we can see that most web performance data is clustered around the 3 – 5 second set of page load time buckets. The highest number of web performance data occurrences is in the four-second bucket (8,474), and the second-highest is in the three-second bucket (7,857).

In other words, when asked, “What is the average performance for our end users?”, this histogram suggests the answer is, “The average performance for our end users is around three to four seconds.” However, as we can see, there are data points in the 10-, 11-, and 12+ seconds buckets as well, i.e., the long tail.

Put another way, the [arithmetic mean] average value of the above dataset is 4,710 ms, and the median value of the above dataset is 4,053 ms. So while “the average web performance” is around three to four seconds, there is an entirely different set of web performance data comprising the long tail. Unfortunately, when using a histogram, the long tail is compressed and consequently more difficult to read than the CDF.

The above CDF is constructed using the exact same data set as for the frequency histogram.

For the above example, the 25th percentile is 3,297 ms. This means:

1. 25% (X axis) of your data is equal to or less than 3,297 ms (Y axis) (75% of your data is greater than 3,297 ms).
2. 35% of your data is equal to or less than 3,598 ms (65% of your data is greater than 3,598 ms).
3. 50% (a.k.a. the median) of your data is equal to or less than 4,053 ms (50% of your data is greater than 4,053 ms).
4. And so on, for each percentile on the X axis

The true power of the CDF comes in its taper points (which is why this type of visual is sometimes referred to as a “hockey stick” chart). In this CDF, we can see the taper start around the 85th percentile with drastic increases for each subsequent percentile. Evidently, the CDF does a better job of visually conveying the Nth percentiles for the long tails.

In conclusion

The most important aspect of any web performance monitoring program is how fast your website or application is presented to an end user. When looking through this lens, web performance monitoring must include:

• The measurement of specific web performance metrics via synthetic monitoring and RUM
• The proper analysis of collected metric data utilizing:
  • time-based analysis using average or median calculations
  • long tail analysis using a frequency histogram or CDF

Time-based synthetic and RUM data will present different patterns. Synthetic data will present as a smoother line, where RUM data will present as an end user’s “wake up and go to sleep pattern”. When using frequency histograms or CDFs, synthetic and RUM data will exhibit the same general patterns; for example, a frequency histogram for both data sets will have a right-skewed “long tail”.

When it comes to web performance, there is no one-size-fits-all number. As long as you start with your end users in mind and work backward from there, your web performance programs will provide value for you and your business.

FAQs