Page Performance¶
Continuously optimizing the user experience is key to the long-term success of any website. Whether you are an entrepreneur, a marketer, or a developer, Web metrics can help you quantify the experience of your website and uncover opportunities for improvement.
Google's Core Web Vitals¶
Web Vitals is an initiative pioneered by Google that aims to provide unified guidance for quality signals that are essential to delivering a great web user experience.
The metrics that make up the Core Web Vitals will evolve over time. The current set for 2020 focuses on three aspects of user experience—loading performance, interactivity, and visual stability—and includes the following metrics (along with their corresponding thresholds):
Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds after the page first starts loading.
First Input Delay (FID): measures interactivity. To provide a good user experience, the page's FID should be 100 milliseconds or less.
Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, the page's CLS should be 0.1 or less.
To ensure that you meet the recommended target values for most of your users, a good measurement threshold for each of the above metrics is the 75th percentile of page loads, and this threshold applies to both mobile and desktop devices.
Collected Page Metrics¶
| Metric | Type (Unit) | Description |
|---|---|---|
view.time_spent |
number(ns) | Time spent on the page. |
view.loading_time |
number(ns) | The page is ready, with no network requests or DOM mutations. > See Page Loading Time. |
view.largest_contentful_paint |
number(ns) | Largest Contentful Paint, measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds after the page first starts loading. |
view.first_input_delay |
number(ns) | First Input Delay, measures interactivity. To provide a good user experience, the page's FID should be 100 milliseconds or less. |
view.cumulative_layout_shift |
number(ns) | Cumulative Layout Shift, measures visual stability. To provide a good user experience, the page's CLS should be 0.1 or less. |
view.first_contentful_paint |
number(ns) | The First Contentful Paint (FCP) metric measures the time from the start of page loading to when any part of the page's content is rendered on the screen. For this metric, "content" refers to text, images (including background images), <svg> elements, or non-white <canvas> elements.> See w3c. |
view.first_byte |
number(ns) | Time from the page request to the first byte of the page response. |
view.time_to_interactive |
number(ns) | Time required from the start of page loading until the main subresources have finished rendering and the page can quickly and reliably respond to user input. |
view.dom_interactive |
number(ns) | Time when the parser completed parsing the document. For details, see MDN. |
view.dom_content_loaded |
number(ns) | The DOMContentLoaded event fires when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading. For details, see MDN. |
view.dom_complete |
number(ns) | The page and all subresources are ready. For the user, the loading spinner has stopped spinning. For details, see MDN. |
view.load_event |
number(ns) | Fires when the entire page and all dependent resources, such as stylesheets and images, have finished loading. It differs from DOMContentLoaded, which fires as soon as the page DOM is loaded without waiting for dependent resources to load. For details, see MDN. |
About Single-Page Applications (SPA)¶
For single-page applications (SPA), the RUM browser SDK uses the loading_type tag to distinguish between initial_load and route_change. The RUM SDK generates a view event tagged with loading_type:route_change. RUM uses the History API to listen for URL changes.
How Loading Time Is Calculated¶
Leveraging the powerful APIs provided by modern browsers, Loading Time monitors DOM changes and network requests on the page.
-
Initial Load: Loading Time takes the longer of the following two:
- loadEventEnd - navigationStart
- time when the page first has no activity - navigationStart
-
SPA Route Change: time when the page first has no activity - time of URL change
Page Activity Status¶
The page is considered active if any of the following conditions is met:
- The page DOM is mutated.
- Static resources are being loaded (loading JS, CSS, etc.).
- There are asynchronous requests.
Note
The page is considered inactive if no events occur within 100ms.
Note
In the following cases, the 100ms standard based on the time since the last request or DOM change may not accurately determine activity:
- The application sends requests to an API periodically or after every click to collect analytics data.
- The application uses "comet" techniques (that is, streaming or long polling), causing requests to remain open indefinitely.
To improve the accuracy of activity determination in these cases, you can specify the excludedActivityUrls configuration to exclude these requests: