Monitor single page applications

Monitor browser applications in RUM and determine whether performance issues affect initial page loads or route changes and trace aggregate metrics to sessions and navigation events for deeper context.

Overview

The application overview in Splunk Real User Monitoring (RUM) provides access to several health areas:

  • UX Metrics: page views, page-load performance, route-change performance, and Web Vitals.

  • Front-end Health: provides JavaScript errors and long-task information.

  • Back-end Health: provides network errors, requests, and time-to-first-byte information.

  • Custom Events: provides rate, error, and duration metrics for instrumented events.

  • Pages: identifies whether performance issues affect initial page loads or route changes and traces aggregate metrics to the sessions and navigation events that explain them.

  • Network Requests: identifies the specific URL or resource associated with latency or errors.

  • Map view: identifies geographic patterns and determines whether network conditions might be contributing to the experience.

Prerequisites

Investigate application performance

Use the UX Metrics page to evaluate the end-user experience for an application, identify slow pages or route changes, and move from high-level performance signals to the sessions and attributes that explain them.

The UX Metrics page provides context for the following types of user experience:

Metric Description
Page Views The volume of initial page loads and route changes
Page Load The time associated with loading a base page
Route Change Duration The time associated with navigation within a single-page application
Largest Contentful Paint (LCP) How quickly the largest visible content element renders
Cumulative Layout Shift (CLS) How much the page layout shifts during loading
Interaction to Next Paint (INP) How responsive the page is to user interaction

Page load time and Route change duration are typically evaluated using the P75 value, which represents the experience of the slower portion of users.

Investigate page performance for browser applications

Use the Pages view to analyze navigation performance by page group, request volume, errors, and duration.

  1. Select an application to monitor from the Real User Monitoring Overview page.

  2. Select the Pages tab.

  3. Select Base pages to investigate initial page loads. Select Route changes to investigate navigation within a single-page application.

  4. Review the metrics for the selected navigation type. Use the following metrics to identify a potential performance issue:
    Metric Description
    Requests Number of page views associated with the page group
    Requests/min Rate of page views over time
    Page Load Time P75 Page-load experience for the slower portion of users
    Errors Errors associated with the page group
    LCP, CLS, and INP Web Vital measurements available for base pages
  5. Confirm whether the results represent real-user traffic. Enable Exclude bots to focus the analysis on sessions from real users. Disable the toggle only when you need to include bot or automation traffic in the results.

  6. Select one of the metric values from the table, then choose Tag Spotlight for <metric name> to investigate the metric or Related Sessions for <metric name> to view the associated sessions.

Use Tag Spotlight to determine whether performance differs by attributes such as browser, operating system, or geographic location. The spotlight view will be automatically filtered to the specific metric you selected.

Use the Related Sessions view to connect the aggregate metric to the individual sessions that contributed to it. In Session Detail, use the waterfall and navigation controls to understand where time was spent. Re-scale the timeline to focus on the selected page load or route change. Use the left-side navigation panel to move between pages visited in the session. Follow APM links when available to determine whether latency originates in the front-end or back-end.

Exclude bots

The Exclude bots toggle is available in the filter bar on RUM pages that support filtering. It is enabled by default.

When enabled, RUM excludes traffic identified as bots or automation users in browser applications, so that performance metrics represent real-user activity more accurately. The filter is based on the is_real_user attribute, which is derived from bot and automation signals in the user agent data.

To investigate automation traffic, turn off the switch and refresh the results.

How Splunk RUM calculates PCT

Splunk RUM calculates page completion time for single-page applications by watching page-loading activity after a route change. The quiet timer starts when the page or route starts. If RUM detects monitored activity, such as matching network requests, media loading, or resource-timing entries, it keeps the page open until that activity completes. After the last monitored activity ends, RUM waits for the configured quiet period before completing the page measurement. In version 3.1.0 and later, the default quiet period is 1 second. In version 3.0.x, the default was 5 seconds. The shorter default helps prevent unrelated background activity from extending page-load measurements.
Note: By default, pending activity from a previous page or route is cleared when a new navigation starts. This helps avoid carrying background work from one route into the next page completion measurement.
Example:
JSON 
SplunkRum.init({
  spaMetrics: {
    quietTime: 1000,
    maxResourcesToWatch: 50,
    ignoreUrls: [
      /analytics/i,
      'regex/\\/polling\\/status/i',
    ],
    clearLoadingResourcesOnNewPage: true,
  },
});

Troubleshooting

  • Ensure you're using Splunk RUM browser agent version 3.1.0 or later. Some features are not available on older agent versions.
  • Confirm that spaMetrics is enabled in your Splunk RUM browser agent configuration.
  • Monitor for any network or media resources that may stall loading, as this can delay PCT calculation.