Noibu is committed to minimizing the impact on your website's performance. While it's impossible for a solution like Noibu to have no impact whatsoever, we implement all operations with performance in mind. To ensure the best possible outcome, we've established multiple processes to monitor the performance and availability of our script:
Manual testing before script changes are pushed to production
Before changes are pushed to production, engineers manually test the updates on various eCommerce platforms. Through an extension run on Google Chrome, Safari, and Firefox, we inject the script into our browsers and execute dummy purchases on a subset of customer websites. Throughout this process, we check for performance impact, error creation, and responsiveness of the websites. Once we conclude the changes are safe, and won't cause additional latency, we push the update to production.
Error logging
In order to constantly monitor our script’s performance and availability, we have a mechanism in place to capture script failures and document suspicious activity. Our script is also capable of disabling itself once it starts congesting the network. Noibu's engineering team is alerted when new errors occur on any of our customer websites, and resolving these errors is a top priority.
Constant performance improvements
Noibu's engineering team is constantly working on data input and performance quality. Our ultimate goal is to ensure minimal performance impact.
The sections below outline elements that can impact performance.
To detect revenue-impacting errors, Noibu's script captures these types of data:
Error data
Data on specific JavaScript and HTTP errors is also captured by the Noibu script. To catch as many errors as possible, our script instruments existing code to catch hidden errors. This means the Noibu script wraps existing code to try to find errors that were previously not reported to the console. However, because the Noibu script will appear at the top-level of any code it wraps (e.g. event handler functions), Google Lighthouse will sum up the performance impact (TBT or execution time) of all of this code and report it as associated with the Noibu script. This means that Lighthouse may report Noibu as causing significant latency depending on what code it wraps, but it does not mean the script is causing latency.
Session re-construction
To re-create session videos, Noibu monitors live mutations on the website and stores those mutations. A website mutation could be:
A click
A carousel image changing
A CSS animation
Adding an item to cart
This information re-construction is the most expensive process, and Noibu has invested heavy engineering work to make the process as efficient and as accurate as possible.
To calculate Annualized Revenue Loss on errors, offer session replay videos, and perform other in-app features, data collected is sent to our backend servers. This happens through two methods:
POST requests
Noibu sends page and error information via POST requests. We only communicate with this endpoint when we detect that a user might be leaving the page, as when a user changes tabs, closes the browser, or changes pages. These requests are typically very short–1-100ms–and do not add any latency to your website. We reduce the amount of information sent per POST request by splitting the information into smaller pieces and sending those pieces individually.
WebSockets
Noibu sends session recording activity via a WebSocket to preserve performance. A WebSocket is a stream of information, and once opened it has to be explicitly closed. This differs from traditional requests that close themselves as soon as they receive a response from the server. We keep our sockets alive for the entire user journey in order to transmit all the session recording information. For that reason, you will see that this request is Pending for the entirety of the user session.