1. Home
  2. Product Guides
  3. Real User Monitoring
  4. For Web
  5. Performance metrics

Performance metrics

Real User Monitoring captures performance metrics from real user experiences with your application. The following documentation lists the performance metrics captured for pages, virtual pages (Single Page Applications), and XHR/AJAX calls.

Load time: The time it takes for the entirety of the page to load.

First Paint (FP): Measures the time between navigation and when the browser renders the first pixels to the screen, rendering anything that is visually different from what was on the screen prior to navigation.

First Contentful Paint (FCP): Measures when the browser renders the first bit of content from the DOM, providing the first feedback to the user that the page is actually loading.

First Paint, First Contentful Paint & Load Time Infographic

For each specific page, given that sufficient real user traffic is available, you can see its performance against further metrics, introduced by Google as core web vitals.

Each metric is presented as the average score over your selected timeframe. To most closely reflect scores considered by Google, set the timeframe to use the last 28 days.

The bar chart underneath the score details the according page load distribution, giving you an indication of the percentage of users with good, mediocre and poor experiences for this specific metric. Google considers a page passing their compliance if it meets the "good" targets at the 75th percentile for all of the above three metrics.

Largest Content Paint (LCP): Measures the time for the largest parts of content to be rendered on the screen. This can be any element(s) in the document object model (DOM), which means any text, image, or SVG is applicable. LCP is useful for understanding how long it takes for your website’s main content to appear on the page.

The largest content of a website is often used as a proxy measurement for the piece of content a user is looking for when they visit your website. Therefore, the longer it takes for this content to load, the longer users are waiting before they can see what they need.

First Input Delay (FID): Measures the time it takes for a browser to respond after a user interacts with your website. This is useful for understanding how long it can take for sensitive actions to operate. For example, a sign-in form to log users into your service or an "add to cart" button on an e-commerce website.

Cumulative Layout Shift (CLS): A value between 0 and 1 which measures the number of unexpected layout shifts occurring between a page loading and when it is hidden. The layout shift score is a calculation of the impact fraction (total visible area the element changes between two rendered frames) and the distance fraction (distance it has moved relative to the viewport).

CLS is useful for understanding how stable a page layout is. For example, if a user is trying to navigate to a different article by clicking a link, but it then moves due to an image loading in (or another page layout shifts) the user will have a frustrating experience.

Core Web Vitals

View Duration: The duration of time which the user has spent viewing this virtual page.

XHR Response Time: The time it took to receive a response for all XHR calls made on the page.

Load time: The time it took for the XHR request to respond.

Page Speed Rating

Real User Monitoring displays a Page Speed Rating on the performance tab. The rating is based on average page load time, and follows these categories:

  • Excellent: <500ms load time
  • Good: 500ms - 1000ms load time
  • Needs work: 1000ms - 4000ms load time
  • Poor: >4000ms load time

When drilling into the performance diagnostics for a specific page, you can see a colored chart breaking down the portions of load time spent in DNS, Latency, SSL, Server, Transfer, Render and Children. This data is an average of the values for each page view within the time range. The section below outlines how RUM calculates these datapoints.

Load time details:

All of the timings listed below access values from the window.performance.timing object.
This means in the context of timing we are referring to window.performance.timing.

note: These formulas have been simplified to make for better reading. Additional checks and data validation is done under the hood.

The time it takes for the nameserver lookup to resolve.

We calculate this using the following formula:
(timing.domainLookupEnd - timing.fetchStart) - (timing.domainLookupStart - timing.fetchStart)

The time it takes for the host server to receive and process a request for an asset.

We calculate this using the following formula:
(timing.connectEnd - timing.fetchStart) - (timing.connectStart - timing.fetchStart)

The time to complete an SSL handshake.

We calculate this using the following formula:
(timing.secureConnectionStart - timing.connectStart) - timing.fetchStart

The time it takes for the server to compute your code.

We calculate this using the following formula:
timing.responseStart - SSL - Latency - DNS

The time the page has to wait for assets to load from the server.

We calculate this using the following formula:
timing.responseEnd - timing.responseStart

The time it takes the browser to apply stylesheet rules and compute JavaScript.

We calculate this using the following formula:
timing.domContentLoadedEventEnd - timing.responseEnd

The time for asynchronous assets to process - this refers to all requests loaded by the page up until onLoad (includes scripts, stylesheets, images and XHR requests).

We calculate this using the following formula:

((timing.domComplete - timing.fetchStart) ?? timing.duration) - ((timing.domContentLoadedEventEnd - timing.fetchStart) > (timing.responseEnd - timing.fetchStart) ? (timing.domContentLoadedEventEnd - timing.fetchStart) : (timing.responseEnd - timing.fetchStart))

On this page: