RudderStack JavaScript SDK Enhancements: Beacon Support

The RudderStack Javascript SDK, at its core, is built to provide guaranteed delivery of events. The main challenges around this are tracking event data on the server and network failure, page unloads, etc. This post will talk about our latest enhancement to the JS SDK - adding Beacon support making it more efficient, fast, and easy to use.

Different Mechanisms we use to Mitigate Challenges Around Tracking Event Data.

Until recently, we were only supporting sending event data to the server using XMLHttpRequest with a persistent queue. Whenever the SDK receives an event, it offloads it to the queue and returns immediately. The queue keeps on pulling event data and sends it to the server using XMLHttpRequest.

To keep in sync with other popular event tracking tags out there, we enhanced our SDK to support sending event data using the browser Beacon API. We have now added support for sending the event payload using the navigator.sendBeacon browser utility, which asynchronously sends a small amount of data over HTTP to the RudderStack server.

Pros and Cons of Using Beacon API

Pros

• With all the benefits it has over fetch and XMLHttpRequest, like being a more performant, Beacon queue to process sending events when the browser is less busy, etc.
• Our SDK is sending event data as JSON, which allowed CORS optimization on the Beacon's part.
• Lesser instrumentation code compared to other event sending mechanisms, leading to less compile time for the SDK. We wanted to drop our persistent queue further to reduce the SDK size further, but we are still using it due to the below-mentioned limitation; we can call it the wrapper queue.

Cons

• Failed event retries are not possible with a Beacon request as it doesn't support getting the response code.
• Beacon requests have a size limit.
• The Beacon queue can get full (related to point 2 above). We wanted our SDK to support sending events for this scenario. When we failed to push event data to the Beacon queue, we kept our persistent queue to retry, pushing such failed events to the Beacon queue. Once some events are being sent to the server, Beacon can accept more events. This is required for sites that track more events/sec through our SDK than Beacon can dequeue.

Pushing events to the Beacon queue is faster compared to the XHR instrumentation. You may see some performance improvements in the JavaScript SDK.

The Beacon requests are optimized because the browser waits until the CPU load is lower or until the network is free before making the actual requests. This can lead to better website performance.

Read more about other JavaScript SDK enhancements in our documentation.

Sign up for Free and Start Sending Data

Test out our event stream, ELT, and reverse-ETL pipelines. Use our HTTP source to send data in less than 5 minutes, or install one of our 12 SDKs in your website or app. Get started.