Real User Monitoring (RUM) is one of the most common approaches to perform web monitoring. It is designed in a way to be as unobtrusive as possible. With RUM, it is possible to gain insights into the following key metrics:
Communication / network time
Network time starts when a user clicks on a link until the backend server responds to it. RUM can provide an overview of how much time is needed by your web application to communicate browser with the server. This is also known as backend call in categorical terms.
DNS lookup
DNS resolution holds a paramount significance since it is the first interaction between a customer and website. RUM monitors the primary milestones and data when the user waits for the application while loading or clicking such as:
- DNS resolution
- SSL encryption
- TCP connect time
- Page render time
- User think time
- First-byte transmission
- and more…
DOM processing
DOM is an API for valid HTML and well-formed XML documents. DOM processing time generally refers to the time spent on parsing the HTML and XML into its DOM (document object model) and retrieving/executing synchronous scripts.
Page rendering time
RUM can monitor the time taken by a browser in processing the content of a page including static content and scripts. By doing so, it helps you understand the actual time spent in processing the page.
Note that if a script on the page dynamically inserts or loads elements after the server or CDN finished working, RUM cannot capture and measure the performance.
Page ready time
RUM can provide a breakdown of how loading time for each page of your website looks like. This usually sums up the total amount of time spent on: Communication/Network Time, DNS Lookup Time, DOM Processing Time, and Page Rendering Time.
Benchmarking CDN using RUM
All CDNs were created differently and may have different standards and settings. So comparing the whole page load timeline along with metrics mentioned above CDNs to CDNs without any standardization may not proof insightful as their starting points are already different.
When measuring the performance of different CDNs using RUM, it is important to take the followings into consideration:
- Unified measurement object – An element that can be used in a performance test, such as a PNG image file. Once decided, this should be the only object to measure for the performance test across all competing CDNs.
- Cache policy standardization – Different CDNs have different cache policy, which will directly impact the test result. It is crucial to make sure the measurement object is cached in CDN.
- Crafting HTTP(S) request – HTTP request is made to fetch the measurement object, thus HTTP request must be standardized as well. For example, request header [Cache-Control: No-Cache]. This header indicates the CDN to ignore the cache object in the edge node but to get from origin. Before implementing any cache/query string, we need to understand why and how it works differently in those to-be-measured CDNs.
- Other conditions – There are some other factors to consider on a client’s side. For instance, test results with an underperforming 3G mobile client may be unlikely for the CDN performance.
mlytics is well taking these factors into consideration when building the platform. All data presented on the platform are all measured based on the same baseline to assure fair and precise data not only for the system to make its decision but for users to understand the trend correctly.