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.
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:
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.
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.
Tips for managing BlueConic performance
- 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.