BlueConic performance

This article offers some insight into how BlueConic works and provides you with tips on how to keep performance of your server in the best shape.

Request flow

To get a better understanding of how BlueConic works from a browser's point of view, it is important to break down the client-side performance into three parts:

  • The loading time for the first page view of the first visit
  • The loading time for subsequent page views
  • The script execution time

The following request flow visualizes all three aspects:

CSFW___request_flow.png

The first request from the browser to BlueConic loads the BlueConic client-side API. This request is triggered by the script that has been placed on every page of the website.
Our script is being served by the Amazon CloudFront Content Delivery Network which ensures speedy delivery from a server location near the visitor. Because this script rarely changes, it can usually be retrieved from the browser cache.

Next, the API triggers a request that loads the visitor's profile, profile properties, and the configuration of the relevant interactions (dialogues, listeners, connections) for the current page view / referrer. 

The visitor is recognized by a cookie ('BCSessionID') which contains a unique identifier. If no profile is available, a new one will be created and the unique identifier for that new profile is returned to the browser in a cookie.

To be able to execute the relevant interactions, the JavaScript plugins and required libraries are now loaded into the browser. All plugins (and libraries) that have active connections, listeners, or dialogues in BlueConic are loaded at once for optimal cache-ability.

After the plugins and libraries have loaded, the scripts are executed. Script execution time is primarily determined by the number and nature of configured listeners and dialogues.

Tip: Restrict your listeners as much as possible to those URLs where the listeners are actually relevant. This article offers tips on how to specify URL restrictions.

Tip: Deactivate or remove listeners and dialogues that are no longer relevant. 

Tip: Bundle listener rules as much as possible into a single listener.

 

FAQ

Q: I see multiple requests going back and forth between the browser and BlueConic?

A: Correct! The number of requests depends on the configured connections, listeners, and dialogues and the actions of the user. These requests are all asynchronous and will not block page rendering (i.e. they will not delay the "DOM ready" event).

Q: Is the page loading time affected by BlueConic?

A: Yes, but the effect is only fractional and should not be noticeable to the visitor due to the use of asynchronous requests. Our script is being served by Amazon CloudFront and will not be impacted by high traffic volume on your websites. Due to the extra requests, the DOM "load" event will be delayed.

Q: Some requests seem data heavy?

A: Specifically the first page view of the first visit will see requests that transfer a lot of data as the client-side API, plugins, and library have to be transferred to the browser. However, the API, plugins, and library requests are static and will be cached for a year. Once the browser has these, subsequent views will retrieve them from the browser cache. As a result subsequent views will only use small REST calls. BlueConic uses minification and gzip to keep transfers to a minimum.