--- title: PageViewTiming: Async or dynamic page details source: https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/pageviewtiming-async-or-dynamic-page-details --- Browser monitoring's [`PageViewTiming` event](/attribute-dictionary/?event=PageViewTiming) sends each data point as a separate event as soon as it is available. Because we do not restrict the timing, you can receive first paint or first interaction data regardless of when it fires. This document describes why and how to use `PageViewTiming` and its attributes to query data about your site, component loading, and user performance metrics, both from visual and responsiveness standpoints. ## Why use PageViewTiming? [#why-pageviewtiming] If your application uses asynchronous or dynamic pages, you may need additional details about site or component loading. But pages can load content in many different ways, and users control when they interact with that content. This is why some user-centric performance metrics happen outside the standard window onload (page load time) in the browser agent. For example, users may become impatient and begin clicking as soon as content is on the webpage. Or, they may wait to use the page until long after content is loaded. The `PageViewTiming` event provides a more real-time delivery mechanism that does not have a dependency on any other event. The additional metrics can help you understand how users experience your site, both from visual and responsiveness standpoints. ## Support for Google's core web vitals As of [agent version 1177](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1177) for browser monitoring, we have full support for [core web vitals](https://web.dev/vitals/#core-web-vitals). This feature is available in all flavors of the agent (Lite, Pro, or Pro+SPA). Note that the metrics that make up core web vitals [evolve](https://web.dev/vitals/#evolving-web-vitals) over time. The current set focuses on three aspects of the user experience: loading, interactivity, and visual stability. It includes the following metrics and their respective thresholds: - **[Largest contentful paint (LCP)](https://web.dev/lcp/)**: measures loading performance. To provide a good user experience, LCP should occur **within 2.5 seconds** of when the page first starts loading. - **[Interaction to next paint (INP)](https://web.dev/inp/)**: measures latency of all user interactions with a page. To provide a good user experience, pages should have a INP of **less than 200 milliseconds**. - **[Cumulative layout shift (CLS)](https://web.dev/cls/)**: measures visual stability. To provide a good user experience, pages should maintain a CLS of **less than 0.1**. For each of these metrics, to ensure you're hitting the recommended target for most of your users, a good threshold to measure is the **75th percentile** of page loads, segmented across mobile and desktop devices. To learn more, watch our [Nerd Days talk](https://fast.wistia.net/embed/channel/nb8bpgbntl?wchannelid=nb8bpgbntl&wmediaid=n7p4x6skee) on perceived performance. ## Detailed visual, interactivity, and responsiveness metrics [#interactivity-metrics] The `BrowserInteraction` and `PageView` events end their reporting when they receive the [page window load](https://docs.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/page-load-timing-process) (or window load and AJAX) timing. However, paint and interactivity metrics can happen at any time. `PageViewTiming` delivers these metrics as a separate event to: - Account for the variability in this timing. - Avoid setting an arbitrary timeout. - Prevent holding `BrowserInteraction` and `PageView` events indefinitely. | Additional data | Comments | | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `firstPaint` and `firstContentfulPaint` | The [`firstPaint`](/attribute-dictionary/?event=PageViewTiming&attribute=firstPaint) and [`firstContentfulPaint`](/attribute-dictionary/?event=PageViewTiming&attribute=firstContentfulPaint) attributes already are available with `BrowserInteraction` and `PageView` events. However, they are not always reliably captured before the window onload event fires. Using `PageViewTiming` gives you a way to capture these metrics even if they happen after the original page load time. This gives you a better understanding of the correlation between responsiveness of that load event and the visual rendering of your content. | | `largestContentfulPaint` | The [`largestContentfulPaint`](/attribute-dictionary/?event=PageViewTiming&attribute=largestContentfulPaint) metric is available with [agent version 1163 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1163). It reports the render time of the largest content element visible in the viewport. Google's research found that looking at when the largest element was rendered was a more accurate way to measure when the main content of a page is loaded and useful. For more information about this metric, including limitations and considerations, see the [w3c draft](https://wicg.github.io/largest-contentful-paint/). We also report the cumulative layout shift score attribute with LCP. This attribute is reported as `cumulativeLayoutShift`. Largest contentful paint is one of three metrics identified by Google as the [core web vitals](https://web.dev/vitals/). LCP values up to 2.5 seconds are considered "Good," between 2.5 and 4 seconds are considered "Needs Improvement," and above 4 seconds are considered "Poor." | | `firstInteraction` and `interactionToNextPaint` | With the addition of [`firstInteraction`](/attribute-dictionary/?event=PageViewTiming&attribute=firstInteraction) and [`interactionToNextPaint`](/attribute-dictionary/?event=PageViewTiming&attribute=interactionToNextPaint), you can quickly determine the ways that your users are interacting with that visual content. These metrics tell you not only when they interacted, but what type of interaction (mousedown, pointerdown, etc.) and how long it took for them to receive a response from your site. The `interactionToNextPaint` metric lies in the middle of `FirstContentfulPaint` and Time to Interactive (TTI) metrics. It measures the time between when a first input can be made and when the browser's main thread is able to respond to any interactions. We also report the cumulative layout shift (CLS) score attribute at the moment of the user's first interaction. This attribute is reported as `cumulativeLayoutShift.` INP is one of three metrics identified by Google as the [core web vitals](https://web.dev/vitals/). An INP score of 200 ms or less is considered "Good," between 200-500 ms is considered "Needs Improvement," and above 500 ms is considered "Poor." | | `cumulativeLayoutShift` | [Cumulative layout shift (CLS)](https://web.dev/cls/) is available with [agent v1177 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1177). CLS is an important, user-centric metric for measuring [visual stability](https://web.dev/user-centric-performance-metrics/#types-of-metrics) because it helps quantify how often users experience unexpected layout shifts. A low CLS helps ensure that the page is [delightful](https://web.dev/user-centric-performance-metrics/#questions). Cumulative layout shift is one of three metrics identified by Google as the [core web vitals](https://web.dev/vitals/). CLS scores up to 0.1 are considered "Good," between 0.1-0.25 are considered "Needs Improvement," and above 0.25 are considered "Poor." | | `interactionToNextPaint` | [Interaction to next paint (INP)](https://web.dev/inp/) is available with [agent v1227 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1227). INP is a newer metric for measuring [runtime responsiveness](https://web.dev/user-centric-performance-metrics/#types-of-metrics) and user-perceived performance. It measures the largest latency between user interactions and page response or repaints. This is an experimental but identified-as-significant metric added in [Web Vitals](https://github.com/GoogleChrome/web-vitals) v3. INP scores up to 200 ms are considered "Good," between 200-500 ms are considered "Needs Improvement," and above 500 ms are considered "Poor." | | `timingName` | You can review different types of activities with the `timingName` attribute, such as `firstPaint`, `firstContentfulPaint`, `firstInteraction`, `largestContentfulPaint`, `pageHide` and `windowUnload`. For example, a `PageViewTiming` event may have a `timingName` of `firstPaint` and a `firstPaint` value of `.03`. The event will also include all default attributes included with the standard `BrowserInteraction` and `PageView` events. | | `elementId` | This is the `Id`, if specified, of the `largestContentfulPaint` element. This value will only be reported with the LCP metric. This value can be `null`. | | `elementSize` | This is the reported size of the `largestContentfulPaint` element. This value will only be reported with the LCP metric. | | `pageHide` | The `pageHide` event, available with [agent v1177 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1177), is sent when the document becomes hidden to the user. In modern practice, this signals the _potential end_ of a user session most reliably. This event always accompanies `windowUnload` if that occurs, but it can also fire separately when the user switches tab. In that case, the unload isn't fired. We also report the cumulative layout shift (CLS) score attribute with `pageHide`. This attribute is reported as `cumulativeLayoutShift.` | | `windowLoad` | The `windowLoad` event is available with [agent v1177 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1177). This is fired when the whole page has loaded, including all dependent resources such as stylesheets and images. For supporting documentation and browser compatibility for the `windowLoad` event, see the [MDN Web Docs site](https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event). We also report the cumulative layout shift (CLS) score attribute with `windowLoad`. This attribute is reported as `cumulativeLayoutShift.` | | `windowUnload` | The `windowUnload` event, available with [agent v1163 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes/browser-agent-v1163), is sent when unloading of the page is detected. In modern practice, this is based off the window pagehide event firing and means that the user is navigating away. We also report the cumulative layout shift (CLS) score attribute with `windowUnload`. This attribute is reported as `cumulativeLayoutShift`. | ## Compatibility and requirements [#requirements] Requirements: - Meets [install requirements](https://docs.newrelic.com/docs/browser/new-relic-browser/getting-started/compatibility-requirements-new-relic-browser). - Reporting of this event requires [browser agent version 1153 or higher](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes). Follow our [Browser agent release notes](https://docs.newrelic.com/docs/release-notes/new-relic-browser-release-notes/browser-agent-release-notes) to find out when new metrics are released. These metrics are supported by the following browser versions. For unsupported browsers, no `PageViewTiming` events will be recorded. | Metrics | Supported browser versions | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `cumulativeLayoutShift` | - Chrome 79 - Metric is elevated to stable; changes in metric definition will be reported in this log. - Chrome 77 - Metric exposed via API: [Cumulative layout shift](https://web.dev/cls/) available via [Layout Instability API](https://github.com/WICG/layout-instability) | | `firstPaint` `firstContentfulPaint` | - Chrome 60 or higher for desktop and mobile (Android webview and Chrome for Android) - Opera 47 or higher for desktop - Opera 44 or higher for Android mobile - Samsung Internet for mobile | | `largestContentfulPaint` | - Chrome 77 or higher for desktop and mobile | | `interactionToNextPaint` | - Chrome 96 or higher - Edge 96 or higher Per web-vitals API, support is determined by [PerformanceEventTiming.interactionId](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceEventTiming/interactionId#browser_compatibility). | | `pageHide` | This event is currently supported by most modern browser versions, except for Safari below 14.1 (desktop) or 14.5 (iOS). [Compatibility matrix via MDN documentation](https://developer.mozilla.org/en-US/docs/Web/API/Document/visibilitychange_event#browser_compatibility). | | `windowLoad` | This event is currently supported by all browsers on desktop and mobile. [Compatibility matrix via MDN documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/load_event#Browser_compatibility). | | `windowUnload` | This event is currently supported by all browsers on desktop and mobile. [Compatibility matrix via MDN documentation](https://developer.mozilla.org/en-US/docs/Web/API/Window/pagehide_event#Browser_compatibility). | ## CumulativeLayoutShift [#cumulative-layout-shift] Cumulative layout shift (CLS) is a metric measuring the stability of the content on a webpage. For a complete description, see [web.dev/cls](https://web.dev/cls/). ### How is CLS captured in New Relic Shifts in page layout as reported by the [Layout Instability API](https://developer.mozilla.org/en-US/docs/Web/API/Layout_Instability_API) are aggregated throughout the life of the page and reported as an attribute on all `PageViewTiming` events, representing the CLS value when that event occurred. Using this model, users can look at their CLS value at different points in the page's life; for example, CLS values up until the first-time users interact with the page or hide the page. ### Approximating other CLS sources Lighthouse captures CLS value only up to the time when a page is loaded, which is useful in a development or lab environment. You can approximate Lighthouse values by looking at the `windowLoad` `PageViewTiming` event. CrUX report uses values captured over the lifespan of the page, which is useful to analyze worst-case shifts in a RUM environment. You can approximate CrUX values by looking at the CLS attribute on the `windowUnload` `PageViewTiming` event. These values will not be exactly the same because of different sample sets and a difference in how values from long-lived web pages are included. The New Relic browser monitoring agent captures CLS when the page unloads, while CrUX collects and updates the metric throughout the lifespan of the page. ### How CLS is aggregated As of July 2021, Google has updated the way CLS values are aggregated. Browser monitoring agent versions v12xx use the method described in [Evolving the CLS metric](https://web.dev/cls-web-tooling/). **Browser monitoring agent v12xx or higher:** Layout shift values are captured in windows. Layout shifts that occurred within 1 second of each other, but no more than 5 seconds between the first and last shift, are part of the same window. A CLS score represents the sum of layout shift values from the window with the highest sum of layout shift values. **Prior to Browser agent v12xx:** A CLS score represents the sum of all layout shifts that occurred up until that point in the page's life. ## Query your event data [#insights-queries] Here are some sample queries for the event data to help you get started. **Percentile over time series** Show the 95th percentile of first paint and first contentful paint over a time series: ````sql SELECT filer(percentile(firstPaint, 95), WHERE timingName = 'firstPaint') AS 'fp', filter(percentile(firstContentfulPaint, 95), WHERE timingName = 'firstContentfulPaint') AS 'fcp' FROM PageViewTiming TIMESERIES 1 minute SINCE 1 hour ago ``` ```` **Percentile by transaction and interaction** Show the 95th percentile of interaction to next paint over a time series, faceted by transaction name and interaction type: ````sql SELECT percentile(interactionToNextPaint, 75) AS 'INP' FROM PageViewTiming WHERE timingName = 'interactionToNextPaint' TIMESERIES 1 minute FACET browserTransactionName, interactionType SINCE 3 hours ago ``` ```` **Histogram of delay timings** Show a histogram of interaction to next paint timings faceted by first interaction time ranges: ````sql FROM PageViewTiming SELECT percentile(interactionToNextPaint, 75) WHERE entityGuid = 'xyz' FACET pageUrl SINCE 24 hours ago ``` ````