Recording JavaScript & Sitespeed

General Recording Process

In order to record a web page, the SessionCam tag needs to be embedded as close as possible to the bottom of any page by either inserting our code directly into a page or once a page is “DOM Ready” when using a Tag Manager. When this executes in a browser, a reference to our main recording JavaScript is inserted into the HTML head of the page. The browser will then asynchronously download the 59Kb (gzipped) recorder file from Amazon’s Content Delivery Network (CDN) CloudFront. This code is also cached locally so it’s only downloaded once regardless of how many pages are viewed in a session by a site visitor.

Once downloaded and parsed, the SessionCam recording JavaScript executes and requests configuration data from SessionCam (detailing whether recording is active, any fields that need masking and any settings specific to the site being recorded). If recording is enabled for the current page then SessionCam will bind to native browser events in order to detect changes. In this way, SessionCam’s actions are disconnected from any user interaction happening on the page.

Next, a complete copy of the rendered page HTML is sent back to SessionCam (this enables us to replay pages exactly as they were seen at the time of recording).

Following on from this, if any changes (such as mouse movements, key presses or DOM updates) are detected, then every 1 second an encoded representation of these are sent to SessionCam.

Monitoring SessionCam Network Events

We put a great deal of effort into ensuring that our recording service has as little impact on the performance of your site as possible. This includes both automated and manual testing routines focused on both functionality and performance.

When you have either manually deployed or configured your tag management platform to inject the SessionCam recording tag into a page you will see a number of network events taking place within a browser’s dev tools. These events differ in two fundamental ways:

Synchronous events require a response from a SessionCam server located in AWS, typically to confirm some type of config requirement that allows the SessionCam recorder to correctly record a page, i.e. what masking requirements are in place, or, whether or not to record the page. These types of events will incur a minimal level of latency.

Asynchronous events do not require a response from a SessionCam server located in AWS; these types of events do not incur any latency as there is no return info sent from AWS, i.e. info is just being sent to AWS.

Network Event Name Synch / Asynch Purpose Average Completion Time

 sessioncam.recorder.js

 Synchronous

The call which instigates a copy of the recording JS into any given page.Once the code has been downloaded once it is locally available for the remainder of the visitor's browsing session, so there’s no need to re-download for new pages.

20 - 90ms

We use PingDom to continually measure this. Over the past 6 months - the Average Response Time has been 84ms.

 config.aspx

 Synchronous

The call which ascertains the recording configuration, which is set within the console, and is applied to the top-level hostname.The config call checks for things such as:

  1. Whether recording is enabled for the host or not

  2. How the masking profile has been configured

  3. Whether any custom code should be applied

Variable - dependant upon the extent to which custom masking and/or code has been included in the configuration.

 getPageId

 Synchronous

The call which ascertains the recording configuration specific to the page on which the recorder has fired; this call is different to the config call in that it’s checking as to whether the page on which the recorder has fired has any unique configuration in comparison to the top-level hostname.Here we’re checking for page-specific configuration items such as:

  1. Whether recording is enabled for the page or not

  2. How the masking profile has been configured

  3. Whether any custom code should be applied

Variable - dependant upon the extent to which custom masking and/or code has been included in the configuration.

 saveEvent

Asynchronous (AJAX call)

saveEvent’s are discrete packets of information which we gather during recording. These packets of data contain information pertaining to the inputs completed by a site visitor, including:

  1. Key presses

  2. Mouse/pointer location

  3. Button presses

  4. Gestures, etc...

Generated every 1000ms


Performance Monitoring Tools

SessionCam is sometimes miscategorised as increasing page load times by various performance monitoring tools. These tools often include our AJAX calls (which continue to happen during the lifetime of a page) in their calculations, leading to a false impression of when a page is ‘fully loaded’. This can be demonstrated by firing the SessionCam tag once all content is loaded (after the OnLoad event) and you will observe the same reported increase in page load time by your monitoring tool.

Additionally, although the first three events are synchronous they’ll not occur contiguously. Therefore, aggregating these calls completion times can also provide a misleading indication of the level of latency which is implied.

Assuming you’ve followed the guidance provided in this article you should experience little to no physical impact to a page’s load time.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.