ForeSee Developer Portal

Everything you need to configure and optimize your ForeSee products. Home of developer documentation, implementation guides, and release notes.

Blueprint

Replay Performance

DBA Replay is designed to deliver impressive functionality with minimal impact to the performance of your website. There are three common performance considerations:

  • Download of product files
  • CPU usage during a user's browsing session
  • Transmission of Replay recordings

Download of product files

We use a Content Delivery Network (CDN) to optimize download speed and to follow best practices for caching and compression. On initial load, the Replay product files should have sub-second download times (1). On subsequent loads, there should be no load time due to caching (2).

CPU Usage and Rendering Performance

DBA Replay code is designed to consume minimal CPU resources when capturing page events. In more than 90% of all cases recording with DBA Replay there is no noticeable (<25 ms) site rendering delay.

The following rare cases could lead to rendering delays >100ms:

  • large initial DOM snapshots that need to be processed (>500kb)
  • huge DOM content mutations, for example in Single Page Applications (SPA)
Testing performance impact
  1. Open the website you want to test in your browser by pressing F12.
  2. Open the Chrome Dev Tools and navigate to the "Performance" Tab.
  3. Start a performance recording by clicking the "record" button.
  4. Use the current webpage and generate events that you want to analyze (events such as opening layers, scrolling, navigation flyouts).
  5. Click on the "stop recording" button.
  6. Wait for the processing to finish. You should see the Event Log Tab (Bubble 1).
  7. To easily find entries you can filter the list by name and sort by size (Bubble 2).

Downloading the performance report

If you suspect a performance issue caused by DBA Recording, we might ask you to send us a performance report. To download the report click the button marked with the arrow in the picture below.

Transmissions of Replay to our Servers

In order to minimize the amount of data transmitted, DBA Replay captures only DOM events and user interactions during the site visit. These are later overlaid with the other site assets to produce the DBA Replay sessions.

When local buffering is active, triggering a survey will lead to a small burst in processing because all locally stored data will be sent to the server via WebSocket. In order to not block any rendering, this is done in intervals and incremental transmissions as the user explores the site.

Updated about a month ago

Replay Performance


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.