A user action is an interaction with the web browser that involves a call to a web server, which can potentially have multiple nested calls. A user action can be a page load, an XHR action or a custom action. The key difference among these action types is the way action duration is calculated and that for each type there are different metrics available.
A page load is an actual page loading in your browser. If you enter a URL in your browser and press enter, a page load occurs. During a page load, many resources are loaded, including images, HTML, and CSS.
The action duration in this case is the time required for the complete page load. More specifically, the start time of the user action begins with the W3C
onload handler has completed its task. The
XMLHttpRequests (see XHR actions below) are started by an
onload handler, the user action ends when the
XMLHttpRequest is complete.
Resource timing steps
The following measures are used to chart the duration of specific steps in the page loading process.
|Measure||Description||Definition in terms of W3C specification|
|DNS||Time spent or resolving domain names.||
|Connect||Time spent establishing a socket connection from the browser to the web server.||
|SSL||Time spent establishing a secure socket connection from the browser to the web server.||
|URL Redirection||Time spent following HTTP redirects.||
|Request||Time spent waiting for the first byte of the document response.||
|Response||Time spent downloading the document response.||
|Total||Time between the response being delivered and the
XmlHttpRequest or via
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 were 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 (see the table below) are calculated in relation to this point in time and are based on the initial XHR that triggers the user action.
|Start time||W3C resource timing:
|Request start||Request start W3C resource timing:
|Response start||W3C resource timing:
|Response end||W3C resource timing:
|Callback start||The start time of the first callback that handled the response of the XHR/fetch.|
|Callback end||The end time of the last callback that handled the response of the XHR/fetch.|
|Visually complete||The time at which all content in the browser's visible area is fully rendered.|
|User action duration||Time spent from initial user click through completion of all XHR callbacks and dynamic resources triggered by DOM modifications in the callbacks.|
The Fetch API provides an interface for fetching resources (including 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 Dynatrace to automatically detect and capture Fetch API request information.
To enable Fetch API detection
- Select Applications from the navigation menu, then select the application you want to configure.
- On the application page, click the Browse (…) button in the top right corner and choose Edit to access settings for the specified application.
- Click Async requests and single page apps, then on the Async requests and single page apps page, select the Capture fetch() requests option.
You can also use the settings on the Async requests and single page apps page to enable support detection of
Custom user actions
User action contributors
The duration of a user action can be broken down into three components:
- Network time: the time required for data transfer
- Server time: the time consumed on the server side
- Frontend time: the time required for the browser to render the page
So these components contribute to the overall duration of a user action; hence the term "user action contributors".
Summing up from the description in the previous sections, a user action duration is calculated as follows:
User action duration = (
navigationStart for page loads or "click time" for XHR actions and user navigations like a button click or click on a link
endTimeOfLastXHR: if XHR calls are triggered during the process and aren't finished 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 consumption =
- Network consumption = (
actionStart) + (
- Frontend time = direct from the W3C navigation timings
Click below to view examples of user action contributors:
User action naming rules
Many applications allow users to accomplish the same goal through different UI controls. 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 UI of an application is translated into multiple languages, the same application function or control may appear under varying names. With user action naming rules, Dynatrace can detect such subtle variations and intelligently group related user actions (i.e., 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, the 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 those user actions.