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.
Data Capturing
To detect revenue-impacting errors, Noibu's script captures three types of data:
- User information
- All user clicks and keyboard input are captured and anonymized by our script. This allows Noibu to calculate the most common reproduction steps, understand a customer's funnel progression, and create a textual representation of the customer's journey through your website. The collection of this data adds minimal or no latency to your website.
- 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 recordings
- To record session videos, Noibu monitors live mutations on the website and stores those mutations. A website mutation could be:
- A user click
- A carousel image changing
- A CSS animation
- A user adding a product to their cart
- This information collection is the most expensive process, and Noibu has invested heavy engineering work to make the process as efficient as possible.
- To record session videos, Noibu monitors live mutations on the website and stores those mutations. A website mutation could be:
Network Activity
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.