Improving Snippet Performance and Matching with 3rd Party Analytics

A more performant event logging endpoint (/events), and new JavaScript methods for event timing.

/events Logging Endpoint: Better performance through batching

Our customers care a lot about the performance impact of including our snippet in their web frontend. We’re constantly improving our snippet to make it faster, and we’re happy to announce the /events endpoint: a new logging endpoint for the Optimizely X Web snippet.

Today, our snippet generates one network request per event to be tracked, and there are a lot of events being tracked on any page including:

• Decision events (one per activated experiment)
• Pageview events (one per Page activated)
• Conversions events (clicks, custom events, etc.)

We know that each network request has an impact on page performance, especially during the critical first seconds of page load. This is especially important on mobile devices where each request consumes finite data and battery resources.

With the release of the Event API, we introduced the capability to submit batches of events in a single request. The /events logging endpoint for the JavaScript snippet is an implementation of the Event API.

A few things happen when a snippet is configured to use the /events endpoint:

• As events are triggered, they are appended to a localStorage queue
• Events are pulled off the queue, batched together and sent once per second for the first ten seconds after snippet activation
• Any events that are triggered after this point will be sent immediately, without queueing or batching
• Note: using the /events logging end point may result in a slight decrease in the numbers of unique visitors and conversions displayed on the Optimizely results page as some visitors who load a page and then bounce within the first second will not be tracked

These optimizations may sound simple, but they have the potential to deliver pretty astonishing performance improvements. One of our early adopters reported that:

“[The new snippet] went live this morning. It reduced page load by a full second. That made quite an impact! Keep these changes and improvements coming!”

holdEvents and sendEvents: Granular control over event logging

In addition to improved performance, we’ve also added the ability to control the timing of when the snippet starts to generate requests.

This is implemented through a pair of new JavaScript methods: holdEvents and sendEvents. Here’s how they work:

1. Call holdEvents before the snippet initializes to prevent any events from being logged
2. Call sendEvents later on to start dispatching events

So why would a developer want to control the timing of Optimizely event logging? Two common use cases are:

1. You want to further optimize page load performance by delaying event logging more than one second
2. You want to align the timing of Optimizely’s tracking with third-party analytics

This second use case is really important, and something we think about a lot at Optimizely. We know that our customers expect the numbers on Optimizely’s results page to line up with their analytics solution, which is often the “source of truth” for the metrics they care about most. When we diagnose analytics discrepancy issues, we often find that the root cause is a mismatch in timing of event logging between Optimizely and third-party analytics, where Optimizely begins logging events earlier during page load. By calling holdEvents before the Optimizely snippet begins logging events and then calling sendEvents part of a callback method provided by third party analytics, it’s possible to significantly reduce this timing gap.

Originally, without this update, Optimizely events could be sent before and after 3rd party events. This made it harder to align Optimizely with 3rd party analytics tools as shown in the image below.

With batching in the new snippet, fewer network requests are generated, and request timing is delayed to be closer to that of third-party analytics..

#BBD0E0 »