A user action is an interaction with an end-user interface that involves a call to a web server, which can potentially have multiple nested calls. It is a transformation from one view to another view that is triggered by a user input, for example, a page load, click, or touch.
User action types for web applications
The following types of user actions are available in Dynatrace for web applications:
The key difference among these action types is the way action duration is calculated and the list of available metrics.
A load action is defined as an actual page loading in your browser. If you type a URL in your browser and use Enter, a load action occurs. During this action type, many resources are loaded, including images, HTML, and CSS.
Load action duration
The action duration is the time required for the complete load action. More specifically, the start time of the user action equals the W3C
onload handler has completed its task. The
XMLHttpRequests are started by an
onload handler, the user action ends when the
XMLHttpRequest is complete.
Load action timings
The following measures are used to chart the duration of specific steps in the load action process.
|Measure||Description||Definition in terms of W3C specification|
The time taken to resolve the hostname for a target URL
The time taken to establish a TCP connection to the server (including SSL)
The time taken to secure the connection established to the server
The time taken to follow any HTTP redirects
The time taken to request the page from the server until the first byte is received
The time taken to receive the response
Time to first byte (TTFB)
The time taken until the first byte of the response is received from the server, relevant application caches, or a local resource
The time spent on server-side processing for a page
The time taken to request and receive resources (including DNS lookup, redirect, and TCP connect time)
The time taken by the browser to render a page
The time between DOM loading and Load event start
The time spent checking any relevant application caches
The time taken to execute
The time taken to process the load event
The time taken to execute XHR callbacks
The time taken to render the first non-default background element
First input start
The moment when the user first interacts with a page, for example, clicks a UI control
First input delay
The time from the first interaction with the page to when the user agent can respond to that interaction
First contentful paint
The time taken to render the first bit of content, such as text or images
Largest contentful paint
The time taken to render the largest element in the viewport
Cumulative layout shift
The score measuring the unexpected shifting of visible webpage elements for a load action
The time taken to fully render content in the viewport
The score measuring how quickly the visible parts of the page are rendered
User action duration
The time taken to complete the page load
Dynatrace continuously tracks user interactions with each page. If user interaction leads to
fetch() calls, an XHR action is created. Dynatrace also detects if there are additional XHRs triggered in the callback of the initial XHR and so on. In this case, Dynatrace waits until all requests are finished. By monitoring the DOM, Dynatrace can also identify resources that have been added in the callbacks. Dynatrace then waits until those resources have finished downloading before ending the action.
An XHR action starts with the user's click on a control on a web page. All metrics are calculated in relation to this point in time and are based on the initial XHR that triggers the user action.
By default, RUM captures certain interaction types. You can configure RUM to detect even more interaction types. For details, see Capture additional interaction types for web applications.
The Fetch API provides an interface for fetching resources, including resources across the network. It is similar to
XMLHttpRequest, but the API provides a more flexible feature set. The generic definitions of
Response, and other network request objects in Fetch allow them to be used at any time they are needed, whether it's for service workers, Cache API, or anything that handles or modifies requests and responses. Fetch also supports the Cross Origin Resource Sharing (CORS).
User actions based on the Fetch API appear in Dynatrace as XHR actions. You can configure RUM to automatically detect and capture Fetch API request information.
Custom user actions
User action duration
Below, you can find information on the maximum user action duration in Dynatrace and the user action contributors for web applications.
Maximum user action duration
The maximum user action duration depends on the application type.
The maximum duration of a web user action is 3 minutes. When a user action takes longer than this, Dynatrace reports such an action as a 3-minute action.
User action contributors for web applications
The duration of a user action can be broken down into three components:
- Server time: The time spent on server-side processing for a page
- Network time: The time taken to request and receive resources (including DNS lookup, redirect, and TCP connect time)
- Frontend time: The time taken by the browser to render a page
These components contribute to the overall duration of a user action.
The user action duration is calculated as follows.
User action duration = (
In this calculation
navigationStartfor page loads or "click time" for XHR actions and user navigations, such as a click on a button or a link
When XHR calls are triggered during the process and aren't completed before
loadEventEnd, then the end time of the last XHR call is used instead of the
The user action contributors are calculated as follows.
Server time =
Network time = (
actionStart) + (
Frontend time =
User action duration −
Server time −
View the examples of user action contributors below.
User action naming rules
Many applications allow users to accomplish the same goal using different UI controls and following different paths. When monitoring such applications, it can be difficult to differentiate between actions that have the same result and goal but are executed using different parts of the application UI. Likewise, if the application is translated into multiple languages, the same application function or UI element can appear under varying names. With user action naming rules, Dynatrace can detect such subtle variations and intelligently group user actions that achieve the same goal into logical groups for monitoring.
Dynatrace automatically removes certain common
sessionid tokens from user action names, for example,
jsessionid for Java containers, default
sessionid for PHP, and
CFTOKEN for ColdFusion. Nonetheless, there are numerous session ID variations that may be present in your environment. If Dynatrace doesn't automatically recognize and remove session IDs from certain user action names you encounter, you'll need to configure custom naming rules for your web, mobile, and custom applications.
Key user actions
Most applications include user actions that are particularly important to the success of your digital business. Examples of these actions are signups, checkouts, and product searches. Such key user actions might take longer to execute than others, or they might have the requirement to be of a shorter-than-average duration.
For instance, consider that you've set your global Apdex threshold to 3 seconds. While this threshold might be acceptable for the majority of user actions, it might not be acceptable for a signup user action. Alternatively, there could be a search action that is quite complex and requires more time than the allotted 3 seconds.