Monitoring Page Performance
Incident Management is now generally available! Incident Management is now generally available!

Monitoring Page Performance

When a user visits a page on your website, a new RUM view event is created. The view contains live page load and performance metrics. Performance metrics are sent to Datadog periodically as the page finishes loading and might be empty for a few seconds before they appear in the Datadog UI.

Identifying performance bottlenecks

To find what’s causing a page to under-perform:

  1. Set up and configure RUM Browser monitoring for your application.
  2. From the RUM Applications page, open the Performance Overview dashboard. It provides you with a high-level view of your monitored pages. Apply filters to narrow your search and uncover performance problems.
  3. When you find a page with problem, dive from the overview dashboard quickly into a RUM view that exemplifies the problem by clicking View RUM events to open it in the RUM Explorer, and then clicking a specific user view. The waterfall in the side panel shows performance details, such as load times for resources, that will help you troubleshoot the bottleneck or other issue.
    Diving from Performance Overview dashboard to performance details for a particular view with an issue

Performance metrics for views

Performance metrics are collected for each individual view. These metrics can pinpoint exactly where the problem is occurring when used with the RUM context collected by default (current page view information, GeoIP data, browser information, etc.) and extended with Global Context.

These performance metrics are key for helping you start your investigations:

  • Time To First Byte: How long it takes the server to process the request. If the server is slow, try using APM to understand what’s causing the slowness on the server-side.
  • First Contentful Paint: How long until something is displayed. Check the RUM waterfall for blocking resources and long tasks preventing the browser from rendering content.
  • Loading Time: How long until the page is interactive. Check the RUM waterfall to see if you’re loading too many assets or if some resources are blocking the rendering.

All performance metrics

For information about the default attributes for all RUM event types, see Data Collected. For information about configuring for sampling, global context, or custom user actions, see Advanced Configuration. The following table lists Datadog-specific metrics along with performance metrics collected from Navigation Timing API and Paint Timing API:

AttributeTypeDescription
view.time_spentnumber (ns)Time spent on the current view.
view.loading_timenumber (ns)Time until the page is ready and no network request or DOM mutation is currently occurring. More info.
view.first_contentful_paintnumber (ns)Time when the browser first renders any text, image (including background images), non-white canvas, or SVG. For more information about browser rendering, see the w3 definition.
view.dom_interactivenumber (ns)The moment when the parser finishes its work on the main document. More info from the MDN documentation
view.dom_content_loadednumber (ns)Event fired when the initial HTML document is completely loaded and parsed, without waiting for non-render blocking stylesheets, images, and subframes to finish loading. More info from the MDN documentation.
view.dom_completenumber (ns)The page and all the subresources are ready. For the user, the loading spinner has stopped spinning. More info from the MDN documentation
view.load_event_endnumber (ns)Event fired when the page is fully loaded. Usually a trigger for additional application logic. More info from the MDN documentation
view.error.countnumberCount of all errors collected for this view.
view.long_task.countnumberCount of all long tasks collected for this view.
view.resource.countnumberCount of all resources collected for this view.
view.action.countnumberCount of all actions collected for this view.

Monitoring Single Page Applications

For Single Page Applications (SPAs), the RUM SDK differentiates between initial_load and route_change navigation with the loading_type attribute. If a click on your web page leads to a new page without a full refresh of the page, the RUM SDK starts a new view event with loading_type:route_change. RUM tracks page changes using the History API.

Datadog provides a unique performance metric, loading_time, which calculates the time needed for a page to load. This metric works for both initial_load and route_change navigation.

How is loading time calculated?

To account for modern web applications, loading time watches for network requests and DOM mutations.

  • Initial Load: Loading Time is equal to whichever is longer:

    • The difference between navigationStart and loadEventEnd.
    • Or the difference between navigationStart and the first time the page has no activity for more than 100ms (activity defined as ongoing network requests or a DOM mutation).
  • SPA Route Change: Loading Time is equal to the difference between the user click and the first time the page has no activity for more than 100ms (activity defined as ongoing network requests or a DOM mutation).

Hash SPA navigation

The RUM SDK automatically monitors frameworks that rely on hash (#) navigation. The SDK watches for HashChangeEvent and issues a new view. Events coming from an HTML anchor tag which do not affect the current view context are ignored.

Further Reading