@algolia/algolia-browser-telemetry

Algolia Telemetry

• Fast - Designed with minimal performance overhead in mind. Tested
• Small - 2KB (minified and gzipped) library that . Size Limit controls the size.

The project is Algolia's effort towards providing our users with security about their search implementation by collecting anonymous telemetry data and giving application owners the necessary monitoring platform so that they can effectively monitor and optimize their search performance. The collected data is in no way personately identifiable or shared with anyone outside of Algolia. With other words, this is not a tracking tool, nor will it ever become one.

Browser Support

IE / Edge	Firefox	Chrome	Safari
IE11, Edge	✅	✅	✅

Telemetry module progressively enhances Algolia's search client. In unsupported environments, it gracefully fallbacks to not adding any instrumentation without impacting the search client itself.

Motivation

Similar to many other companies, our service runs on the internet and although we do monitor and probe our server infrastructure, it only gives us a partial view of how our users are experiencing search. The telemetry data will enable us to improve our service on a global scale, prioritize feature development, namely adoption of new HTTP protocols like QUIC and evaluating the impact of new middlewares (load balancer, caches) to the end user search experience.

The telemetry module collects information such as latency, response size and DNS timings as well as reports API errors that the search engine might return so that we can detect downtimes which might not be stricly related to Algolia's infrastructure such as wrongly deleted API keys, bad request parameters etc...

Customer benefits

We will be exposing some of the metrics that we will be computing from your telemetry data, starting with latency, reponse size and the potential errors coming from the engine. It is important that we give you the ability to visualize how your search speed evolves as you make updates to your Algolia index. Our engine is fast by default, but certain configurations and indexing strategies can lead to poor end-user performance, the typical example would be very large record sizes or fetching 1000 hits on page load if there might only 10 be needed. We believe this will encourage users to fine tune settings like hitsPerPage or attributesNotToRetrieve in order to minimize the engine response sizes and create adaptive search experiences.

Telemetry Module design

The telemetry module is built with minimal performance overhead in mind, we worked hard and designed the module in a way where it still reliably collects telemetry data without compromising performance. The module collects data outside of the "critical code path" by using performance observers and queues which process data outside of the main event loop. The module leverages browser micro tasks and requestIdleCallback to collect data - it's design was inspired by the idle-until-urgent pattern.

Example call stack execution: