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.
BlueConic 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:
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.
Note: All BlueConic cookies, including the BCSessionID cookie, should be flagged as Secure on HTTPS websites. If you encounter any cookies that are not Secure, contact BlueConic Support.
Tips for managing BlueConic performance
- Tip: Restrict your listeners as much as possible to those URLs where the listeners are actually relevant.
- 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: BlueConic performance
Below are some frequently asked questions about BlueConic page performance.
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.
Q: Are there any tips about BlueConic performance?
- Tip: Restrict your listeners as much as possible to those URLs where the listeners are actually relevant. Learn how to specify URL restrictions in BlueConic.
- Tip: Deactivate or remove listeners and dialogues that are no longer relevant.
- Tip: Bundle listener rules as much as possible into a single listener.