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
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).
DBA Replay code is designed to consume minimal CPU resources when capturing page events. DBA waits to execute code until DOM-Load is finished, meaning the initial display of the site is never blocked by DBA code. But as all changes on the website are tracked afterward, there may be minimal delays of sub-sequential renderings. In more than 90% of all cases, these delays are below 25ms and are not noticeable by users.
The following rare cases could lead to rendering delays >100ms:
- The following scenarios might lead to rendering delays >100ms:
- huge DOM snapshots (initially) > 500kb
- huge DOM content changes, for example in SPAs
- Very slow end-user devices
DBA code execution load and calculations will always be in some form proportional to the overall size and complexity of the site it is working on. Meaning that sites, that already have a bad performance are affected in a higher grade than optimized sites.
- Open the website you want to test in your browser by pressing F12.
- Open the Chrome Dev Tools and navigate to the "Performance" Tab.
- Start a performance recording by clicking the "record" button.
- Use the current webpage and generate events that you want to analyze (events such as opening layers, scrolling, navigation flyouts).
- Click on the "stop recording" button.
- Wait for the processing to finish. You should see the Event Log Tab (Bubble 1).
- To easily find entries you can filter the list by name and sort by size (Bubble 2).
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.
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 3 months ago