Web performance monitoring is the act of measuring the performance of a given set of metrics to see how fast a website or application is presented to an end user. Metric data is usually gathered via the two main types of performance monitoring: active synthetic monitoring and passive real user monitoring (“RUM”). A web performance monitoring tool takes the raw data that the metrics provide on your website or web applications, collates it, and presents it in a variety of ways so that performance issues can be effectively analyzed and quickly responded to.
The majority of end user response time occurs on the front end, so website performance monitoring is accordingly focused there. This stands in contrast to Application Performance Monitoring (APM), which traces a transaction’s performance through its back end services.
Let’s take a deeper look at web performance metrics and web performance 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 times, server times, response times, file size, 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. 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 to when the client receives the first byte of the request’s response.
- Response Time: The duration 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 length of time it takes for the browser to render the first bit of content from the document object model (DOM). This is an important metric because it provides the first piece of feedback to the user on how the page is loading.
- Largest Contentful Paint (LCP): LCP is a Google Web Vitals metric, which measures when the largest content element on a page becomes visible.
- First Input Delay (FID): FID measures load responsiveness by assessing the time it takes from when a user first interacts with a page to the time when the browser can begin to process responses for 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 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 times, server times, response times, file size, 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:
- 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.
- Web performance long tails versus the average: use frequency histograms or cumulative distribution functions (CDF) to analyze those transactions that take much longer than the 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 is tracking real user traffic and “follows the sun”. Synthetic data, by contrast, will present as a smoother line because the condition of the emulated agents does not change over each 24 hour period. There may be times when either the synthetic dataset versus the RUM dataset will trend in different directions. Therefore, it is important to use both Synthetic and RUM measurement types as part of your web performance monitoring program.
When trending web performance data over time, consider using one of two data aggregation calculations:
- 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.
- Median: the middle number in a series of numbers. When compared to the average, it is computationally expensive to calculate, but is 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 look at the data as a composite to get a holistic view of how end users are experiencing your site. There are two core questions to ask:
- What is the “average” performance for my end users? In other words, what type of performance are most end users experiencing?
- 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 in addition to the average performance time. One way of considering the long-tail is to see it as a useful way to tell you what percent of users are having a bad experience, versus having to guess at it. As opposed to representing only a subset of users, the long tail is a gradient of experiences of all users. Not unlike considering the distribution of wealth in the world, long tail analysis helps determine what portion of users would benefit from your precious web optimization efforts.
There are two important visuals that can help with your analysis:
- The frequency histogram: This type of histogram is broken down into buckets or ranges and shows how frequently web performance data occurs in those buckets. 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.
- The cumulative distribution function (CDF): This shows the relative percentiles of web performance data, and is an exceptionally powerful web performance 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 occurrence of web performance data is the four second bucket (8,474 occurrences) and the second highest occurrence of web performance data is in the three second bucket (7,857 occurrences). 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 occurrences of data in the ten, 11, and 12+ seconds set of 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.
Cumulative Distribution Function
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:
- Twenty five percent (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).
- Thirty five percent of your data is equal to or less than 3,598 ms (65% of your data is greater than 3,598 ms).
- Fifty percent (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).
- 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.
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 CDF, synthetic and RUM data will present in the same general patterns; for example, a frequency histogram for both data sets will have a right skew “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.
This guide has been created by Catchpoint to answer common questions from practitioners about synthetic monitoring. The articles are organized by topic, and they can be read either separately or together as a whole set.
Understand how transaction monitoring complements API monitoring, learn about the best practices and pitfalls, and see a comprehensive list of criteria for picking the right tool for you.
Learn how synthetic monitoring complements real-user monitoring (RUM) or augments RUM for tasks like benchmarking and performance analysis.
Discover how raw data is aggregated, which performance metrics are the most important to keep track of, and how to apply data analytic concepts like Cumulative Distribution Function (CDF) to your data.
Dive into the components of DNS services, their record types, and all of the potential threats or pitfalls that can challenge the stability of your address resolution infrastructure.
Get familiar with content delivery networks (CDN), how they are used, and what aspects of CDNs are the most important to check for optimal caching, routing, and uptime.
Get help comparing synthetic monitoring tools and determine which features are essential for your business’s use cases.
Learn about various API types, the best practices for monitoring and debugging them, the right KPIs to measure, and the important criteria to consider for selecting an API monitoring tool.