10.2 User Actions: Load vs. XHR/Fetch Actions, Visually Complete & Speed Index

In Dynatrace Real User Monitoring, digital experience is not evaluated merely by counting raw HTTP hits or measuring backend server runtimes. Real users experience applications through continuous physical interactions: clicking buttons, opening navigation menus, submitting forms, and waiting for visual content to render on screen.

To represent this human experience accurately, Dynatrace aggregates raw browser events, asynchronous network requests, and DOM mutations into a foundational observability construct: the User Action. Understanding the internal lifecycle of different user action types, their duration calculations, modern visual rendering metrics, and action naming mechanics is a major focus of the Dynatrace Certified Associate exam.

---

1. The Anatomy and Classification of User Actions

A User Action represents a discrete, meaningful interaction performed by an end user on an application interface. Dynatrace structures digital experience into a clear hierarchical model:

$\text{User Session} \longrightarrow \text{User Actions} \longrightarrow \text{Web Requests / PurePaths}$

Dynatrace categorizes all web-based user interactions into three distinct action types:

+---------------------------------------------------------------------------------------------------+
|                                 DYNATRACE USER ACTION TAXONOMY                                    |
+---------------------------------------------------------------------------------------------------+
| 1. LOAD ACTION (Full Document Navigation)                                                         |
|    • Browser navigates to a new URL, reloads page, or submits non-AJAX form.                      |
|    • Tears down current document, creates brand new DOM, downloads HTML, CSS, JS, and images.      |
|                                                                                                   |
| 2. XHR / FETCH ACTION (Asynchronous Single Page Application Interaction)                          |
|    • User clicks button, types text, or changes URL route in a Single Page App (React/Angular).   |
|    • Client JS issues XMLHttpRequest or window.fetch calls without full page reload.              |
|                                                                                                   |
| 3. CUSTOM USER ACTION (Programmatic API Instrumentation)                                          |
|    • Explicitly defined using Dynatrace JavaScript API (dtrum.enterAction / dtrum.leaveAction).  |
|    • Measures non-network UI state changes, client calculations, or custom business steps.        |
+---------------------------------------------------------------------------------------------------+

---

2. Load Actions: Full Navigation & W3C Timing Milestones

A Load Action occurs when a browser navigates to a new web page, clicks an external hyperlink, triggers a full browser reload, or submits a standard HTML form that results in a new document request. During a load action, the browser completely destroys the existing DOM and builds an entirely new document tree.

The W3C Navigation Timing Breakdown

Dynatrace hooks directly into the browser's native W3C Navigation Timing API to deconstruct a Load Action into precise chronological milestones:

|-- DNS Lookup --|-- TCP / SSL --|-- Server Wait --|-- Response --|-- DOM Processing --|-- Onload Event --|
^                ^               ^                 ^              ^                    ^                  ^
navigationStart  connectStart    requestStart      responseStart  responseEnd          domInteractive     loadEventEnd
                                                   (TTFB)

1. Navigation Start (navigationStart): The exact moment the user initiates navigation (e.g., presses Enter in the address bar or clicks a link).
2. DNS Lookup (domainLookupStart to domainLookupEnd): Time spent resolving the domain hostname to an IP address.
3. Initial Connection (connectStart to connectEnd): Time required to complete the TCP three-way handshake, including TLS/SSL negotiation (secureConnectionStart).
4. Time to First Byte (TTFB / requestStart to responseStart): The interval between sending the HTTP request and receiving the first byte of the HTML response payload from the web server or CDN. TTFB serves as a primary indicator of backend server processing latency and network round-trip time.
5. Response Transfer (responseStart to responseEnd): Time taken to download the full HTML document.
6. DOM Interactive (domInteractive): The point at which the browser finishes parsing the raw HTML and constructs the initial Document Object Model (DOM), allowing client-side scripts to interact with elements.
7. DOM Content Loaded (domContentLoadedEventStart to domContentLoadedEventEnd): Fired when the HTML document is fully parsed and deferred scripts have executed, even if external stylesheets, images, and sub-frames are still loading.
8. Load Event (loadEventStart to loadEventEnd): The traditional browser milestone indicating that all secondary resources (images, styles, scripts, iframes) specified in the initial HTML markup have finished loading.

Exam Key Point: The duration of a Load Action starts at navigationStart and ends when all initial markup resources have loaded AND subsequent DOM mutations triggered during page initialization have stabilized.

---

3. XHR and Fetch Actions: Single Page Application (SPA) Observability

Modern web architectures rarely execute full page reloads. Frameworks like React, Angular, Vue.js, and Next.js function as Single Page Applications (SPAs): a single HTML document is loaded once, after which all page transitions, data submissions, and UI updates occur asynchronously using XMLHttpRequest (XHR) or the window.fetch API.

Lifecycle of an XHR / Fetch Action

Because an XHR action does not fire W3C page load events, Dynatrace applies a specialized lifecycle algorithm to measure its boundaries:

[ User Clicks Button ] ──> Action Starts (Timestamp T0)
    │
    ├── JavaScript executes event handler
    ├── Initiates Request A (POST /api/cart) ───[ In Flight: 350ms ]───┐
    ├── Initiates Request B (GET /api/inventory) ──[ In Flight: 700ms ]──────┐
    │                                                                  │     │
    │                                       Request A Finishes (T0 + 350ms)  │
    │                                                                        │
    │                                       Request B Finishes (T0 + 700ms) ─┘
    │
    ├── Framework mutates DOM (Renders cart drawer: 60ms)
    │
[ DOM Mutations Cease ] ──> Action Closes (Timestamp T0 + 760ms)
Total Action Duration = 760 ms

1. Action Trigger (Start Time): The action starts at the exact millisecond of the user interaction (such as a mouse click, key press, or tap event) that initiated the workflow.
2. Network Activity Monitoring: The Dynatrace JavaScript agent monitors all XHR and Fetch requests initiated during the interaction window. If multiple requests are launched in parallel, or if one request triggers a secondary chained request, Dynatrace keeps the action open.
3. Network Completion: Dynatrace waits until the last triggered asynchronous network request finishes transferring its response payload.
4. DOM Mutation Stabilization: Following network completion, frontend frameworks frequently manipulate the DOM (inserting rows, rendering modals, displaying notifications). Dynatrace monitors the DOM using MutationObserver. The action officially closes only when all network calls have resolved and DOM mutations have completely ceased for a stabilization window.

Exam Rule: If a user clicks a button that launches three concurrent XHR requests taking 200 ms, 500 ms, and 850 ms respectively, followed by a 50 ms DOM rendering cycle, the total duration of the XHR User Action is 900 ms ($850\text{ ms} + 50\text{ ms}$). Dynatrace does not average the times or create three separate user actions.

---

4. Custom User Actions: Programmatic Telemetry

Certain client-side interactions do not generate network requests or alter the DOM in a detectable manner, yet they represent critical business operations. Examples include:

• Opening a client-side help accordion whose content was already pre-cached in memory.
• Calculating a complex loan estimate entirely inside client-side JavaScript.
• Measuring a multi-step form where sub-steps occur without network communication.

To monitor these scenarios, developers utilize the Dynatrace JavaScript API (dtrum):

// Start custom action
var actionId = dtrum.enterAction("Calculate Mortgage Estimate", "CustomAction");

// Execute client-side business logic
runMortgageCalculations();

// End custom action
dtrum.leaveAction(actionId);

Custom user actions report durations, errors, and custom business properties directly into the application's RUM dashboard alongside automated actions.

---

5. Visually Complete vs. Traditional Load Metrics

For over two decades, web performance was evaluated primarily using loadEventEnd (the browser window load event). In modern dynamic web applications, however, loadEventEnd has become fundamentally misleading:

• Fires Too Early: In an Angular or React application, loadEventEnd often fires within 1.5 seconds because the initial HTML shell is tiny. However, the user stares at a blank screen or a loading spinner for another four seconds while JavaScript bundles download, execute, and populate the visible viewport.
• Fires Too Late: If a web page includes a slow, hidden third-party tracking pixel, social media widget, or invisible advertising iframe at the bottom of the page, loadEventEnd will be delayed for 8 seconds even though the user was able to read and interact with the primary article in 1.2 seconds.

To solve this discrepancy, Dynatrace pioneered Visually Complete.

How Visually Complete Works

Visually Complete measures the exact point in time when all visual elements within the above-the-fold viewport (the visible screen area without scrolling) have stopped changing.

+---------------------------------------------------------------------------------------------------+
|                         VISUAL PROGRESSION TIMELINE COMPARISON                                    |
+---------------------------------------------------------------------------------------------------+
| Time (s):    0.0s    1.0s    2.0s    3.0s    4.0s    5.0s    6.0s    7.0s    8.0s                 |
| Visual:      [ Blank ] ===> [ Header/Nav ] ========> [ Hero Image/Content ] ========> [ Stable ] |
|                                                             ^                             ^       |
|                                                             │                             │       |
|                                                     Visually Complete              loadEventEnd   |
|                                                         (4.2s)                   (Delayed by slow |
|                                                                                  ad tracker: 7.8s)|
+---------------------------------------------------------------------------------------------------+

---

6. Speed Index: Calculating Perceived Visual Progression

While Visually Complete identifies the single millisecond when the visible viewport reaches 100% stability, it does not describe how smoothly or quickly the page rendered up to that point.

Consider two web pages that both achieve Visually Complete at 4.0 seconds:

• Page A: Displays 85% of its visible text and imagery within 0.8 seconds, with the final 15% (a small footer logo) snapping into place at 4.0 seconds. The user perceives Page A as blazingly fast.
• Page B: Remains a completely white screen for 3.8 seconds, after which all content renders all at once at 4.0 seconds. The user perceives Page B as painfully slow.

The Speed Index Solution

Speed Index measures the rate of visual progress throughout the page load cycle. Mathematically, it represents the integral (area above) the visual progression curve:

$\text{Speed Index} = \int_{0}^{t_{\text{complete}}} \left( 1 - \frac{\text{Visual Completion}(\%)}{100} \right) dt$

• Lower is Better: A lower Speed Index score means that a large percentage of visual content rendered very early in the loading process.
• In the scenario above, Page A will have a low, excellent Speed Index (e.g., ~1,100 ms), whereas Page B will have a high, poor Speed Index (e.g., ~3,800 ms), reflecting true customer experience despite identical Visually Complete endpoints.

---

7. Google Core Web Vitals (CWV) in Dynatrace

Dynatrace natively captures and visualizes Google's Core Web Vitals, aligning digital experience monitoring with search engine ranking criteria and web performance standards:

1. Largest Contentful Paint (LCP): Measures loading performance. Identifies the render time of the largest image, video thumbnail, or text block visible within the viewport.
   • Good: $\le 2.5\text{ seconds}$
   • Needs Improvement: $2.5\text{s} - 4.0\text{s}$
   • Poor: $> 4.0\text{ seconds}$
2. Interaction to Next Paint (INP) / First Input Delay (FID): Measures page responsiveness. Measures the latency between a user's initial interaction (clicking a button, tapping a link) and the next frame update presented by the browser.
   • Good: $\le 200\text{ milliseconds}$
   • Needs Improvement: $200\text{ms} - 500\text{ms}$
   • Poor: $> 500\text{ milliseconds}$
3. Cumulative Layout Shift (CLS): Measures visual stability. Quantifies unexpected layout shifts where elements suddenly move position while the user is reading or attempting to click.
   • Good: $\le 0.1$
   • Needs Improvement: $0.1 - 0.25$
   • Poor: $> 0.25$

---

8. User Action Naming Rules & Key User Actions

By default, Dynatrace automatically generates names for user actions based on detected DOM elements, page titles, or URLs:

• Load Actions: loading of page /catalog/laptops or loading of page "Checkout Portal".
• XHR Actions: click on "Add to Cart" on page /products or click on button#btn-submit.

Custom User Action Naming Rules

In enterprise web applications, default names can quickly become chaotic due to dynamic element IDs (e.g., click on button_9a87f), localized multilingual text (e.g., click on "Añadir al carrito"), or single URLs hosting dozens of distinct workflows. Dynatrace provides User Action Naming Rules allowing administrators to normalize names using:

• HTML element attributes (ID, CSS classes, inner text).
• URL components (path segments, query parameters, anchors).
• Page metadata (HTML <meta> tags, page titles).
• Client-side JavaScript variables (e.g., window.appSection.currentScreen).

Key User Actions: Elevated Business Monitoring

Not all user actions have equal business value. An e-commerce organization cares far more about the speed and reliability of the Complete Order action than a casual click on a Terms of Service link. Dynatrace allows administrators to designate critical interactions as Key User Actions.

Promoting an action to a Key User Action unlocks four critical platform capabilities:

1. Custom Apdex Thresholds: Allows setting an independent, aggressive Apdex target $T$ (e.g., $1.0\text{ second}$ for Place Order) distinct from the global application threshold (e.g., $3.0\text{ seconds}$).
2. Dedicated Anomaly Detection: Enables tailored alerting thresholds for response time regressions, failure rate spikes, and sudden traffic drops specifically for that action.
3. Extended Metric Retention: Stores detailed historical performance metrics for up to 5 years, enabling multi-year seasonal and Black Friday trend analyses.
4. Dashboard Pinning & Service-Level Objectives (SLOs): Enables direct embedding as dedicated dashboard widgets and tracking as formal DEM SLO targets.