Classic Capture and Replay works well for a traditional customer-to-website-interaction scenarios, where everything that runs the application and or website is contained in the response to the customers request.
For scenarios not currently supported by Classic Capture and Replay or for scenarios where the complexity for configuring classic replay makes it prohibitive, consider using DOM Capture and Replay. For example, consider using DOM Capture and Replay when a complicated JavaScript™ runs in a single-page application.
Decide between Classic Capture and Replay and DOM Capture and Replay
There are advantages and disadvantages related to using Classic Capture and Replay or DOM Capture and Replay. Consider the following factors when trying to determine which type of capture and reply solution (Classic or DOM) to implement:
- Different areas of focus for UIC configuration
Both the Classic and DOM solutions require a similar level of complexity when it comes to configuring the UIC.
While Classic replay configuration focuses on ensuring all user interactions are captured, DOM Capture focuses on the strategic capture of trigger events and on optimizing the triggers for snapshots.
- Client-side processing and network bandwidth
DOM Capture incurs additional processing and network transmission cost that is directly proportional to the size of the snapshot and frequency of the triggers.
- Complexity of the replay configuration
Classic replay recreates the entire sandbox within the browser in which the application runs and behaves exactly as the user experienced it. For some types of applications, for example single page applications (SPAs), the configuration required to achieve this can be extensive. In contrast, the replay of DOM snapshots requires minimal replay configuration.
- Tealeaf storage and processing
DOM snapshots require additional storage and processing capacity which is directly proportional to the quantity and size of the snapshots.
For traditional multi-page web applications, consider a "mixed mode solution" with elements of Classic Capture and Replay and judicious use of DOM Capture and Replay.
Optimal UIC configuration is the key to successfully integrating DOM Capture into your capture and replay solution. If you are an existing Tealeaf customer, you can continue to use and extend your traditional Tealeaf capture, replay, events, and technological investments. You do not need to view DOM Capture and Replay as a replacement for Classic Capture and Replay solutions. Instead, consider using DOM Capture and Replay for specific pages, screen views, or elements of interest where additional visibility is needed.
Benefits of DOM Capture and Replay
With DOM Capture and Replay, you have:
- More control over dynamic interaction
- More data in session
- Less Rich Internet Application (RIA) work
Classic Capture and Replay versus DOM Capture and Replay
This table compares Classic Capture and Replay and DOM Capture and Replay:
For Classic Capture and Replay. . . | For DOM Capture and Replay. . . |
---|---|
UI Capture SDK collects the UI event |
UI Capture SDK collects DOM and the UI event |
Uses rendering agent based on user agent |
Does not use rendering agent. |
The Rendering Engine runs JavaScript for dynamic content |
Uses the exact DOM that the user saw at the moment of capture, rather than a simulation by the renderer. |
HTML consists of re-rendered response. |
HTML consists of the response + DOM. |
Performance and DOM Capture and Replay
Using DOM Capture and Replay instead of the classic Capture and Replay can result in faster performance at replay time and a truer replay experience, because:
- Classic capture and replay relies on the Rendering Engine to render a page in BBR, while DOM Capture and Replay uses the captured DOM to display a page in BBR.
Because DOM Capture and Replay does not rely on a rendering process, there are less resources that are involved to display the page, resulting in better performance in BBR.
- Classic capture and replay processes dynamic content when the session is recalled, while DOM Capture and Replay captures dynamic content in the DOM (when it happens to the user the first time).
Because DOM Capture and Replay uses the exact DOM that the user saw at the moment of capture, rather than a simulation produced by a Rendering Engine, DOM Capture and Replay provides a "truer" replay experience.
How DOM diff works
The UIC SDK uses the DOM diff feature to process the differences. By default, this service is enabled. This feature is only active if the DOM Capture feature module is enabled.
In the DOM Capture (Type 12 JSON) message, the fullDOM
property indicates whether the Type 12 message contains a full DOM or DOM diffs. When the fullDOM
property is true
, the Type 12 message contains a full DOM capture. When the fullDOM
property is false
, the Type 12 message contains DOM diffs.
Replay uses the diffs to transparently reconstruct the DOM capture on the server.
The DOM diff feature is available only with specific browsers:
- Internet Explorer 11 and above
- Chrome 42 and above
- Firefox 38 and above
Use DOM diff to reduce the size of the captured session
The DOM diff feature applies only the differences (diffs) for the captured DOM when replaying the session. By processing the DOM diffs only, you can reduce the size of the captured session. Reducing the size of the captured session can improve replay performance.
Note: DOM diff functionality is not supported for replaying Hybrid Mobile apps.
The type of capture performed (DOM diff, Full DOM, or Classic) is controlled by setting specific properties in the UI Capture SDK, as shown in the following table.
To enable . . . | Set the following properties in the UI Capture SDK |
---|---|
DOM diff capture |
|
Full DOM capture |
|
Network / Classic capture |
|