Trading site performance for DX insights? Here’s why you don’t need to

As a digital experience (DX) pro, you’re well aware that site performance is important to earning customer trust. 

After all, nearly 70% of consumers say that a site’s load speed impacts their willingness to buy from that company. And every little bit counts—for every one second delay, website conversion rates drop by over 2%, according to the same survey.

But you also know that consistently winning and retaining customers means continuously improving the digital experience, which requires capturing data. 

Complicating matters, some product analytics and digital experience tools demand a tradeoff: logging that data can ding page performance. But, as shown by the stats above, this results in a lose-lose situation—would-be customers grow impatient at the loading delay and bounce before they can even generate the DX data you’re hoping to capture. 

Luckily, that tradeoff is avoidable when you choose a Digital Experience Intelligence platform like FullStory that has no discernible effect on site performance.

But don’t take our word for it—let’s look at two industry-leading companies who are using FullStory’s Digital Experience Intelligence while maintaining site speed. 

Gap Inc. tries on DX data without compromising performance

With an estimated 50+ million visitors each month, Gap Inc. places a huge emphasis on site speed, which is a key driver of their overall Net Promoter Score (NPS). So, when they began evaluating DXI solutions, the ability to maintain performance was on their list of must-haves. 

Other tools Gap Inc. was evaluating required considerable bandwidth to operate and capture data. On the other hand, when Gap Inc. tested FullStory, they found that FullStory not only collected more comprehensive DX data, it also had no noticeable effect on their site performance. 

FullStory zooms through Carvana’s performance impact test

At Carvana, the product team places a huge emphasis on Core Web Vitals, and thinks of site performance as a feature in and of itself. When evaluating FullStory as a Digital Experience Intelligence solution, the Carvana team was concerned that adding the FullStory data capture script to their site would negatively impact performance. 

So, they decided to put it to the test.

Carvana created their own A/B test—with and without the FullStory script—to ensure that capturing DX data through FullStory wouldn’t hinder their site’s functionality. And, voila! They concluded that despite the massive amount of valuable DX data being logged—from Carvana’s 8 to 14 million unique monthly sessions—FullStory didn’t diminish their site performance. (Not only did they preserve speed, they went on to achieve a 5% lift in cars reserved for checkout with FullStory’s DXI.)

The nuts and bolts of FullStory and performance

How does FullStory ensure that it doesn’t impact page speed? To put it quite simply, the script that FullStory uses for data capture (fs.js) is carefully built with speed in mind. To get more technical, there are three aspects we considered in order to build the most lightweight script possible: Page rendering and interactivity, UI thread, and upload bandwidth. 

For the JavaScript nerds who are still with us, let’s look more closely at each of these. 

Page rendering and interactivity

FullStory uses three techniques to ensure that its script is not allowed to delay rendering or interactivity of your site:

1. The script is very, very small. Zipped, it’s roughly 60KB, which is smaller than most scripts and most images. (For reference, most website images range from 200 to 500KB.)

2. The script is edge-cached on Google’s CDN to reduce fetch time—it typically takes under 20ms to fetch. This is especially important because browsers only allow a fixed number of outstanding resource requests at any given time. The faster the FullStory request completes, the faster it frees up space for other resource requests. 

3. The script is loaded asynchronously. JavaScript requires that an inline script blocks evaluation of a page until it’s loaded, which can impact page load time. FullStory skirts this risk by installing a very small snippet that loads the full fs.js script asynchronously. For perspective, this is the same strategy Google Analytics uses. 

UI thread utilization 

After a browser loads a web page, its most precious resource is CPU time spent in the main UI thread. Since all JavaScript is executed on this thread, a delay of more than about 50ms can result in user-visible slowdowns. FullStory uses a straightforward asynchronous processing technique to avoid these delays. Here’s how it works: 

1. FullStory uses Event Handlers that simply add all user interaction events to an in-memory queue to be processed later, rather than processing them in real time. This means the script does the minimum amount of work possible and returns control to the browser’s event loop. 

2. When it’s time to upload a set of events to the server, FullStory’s data capture script processes each outgoing event, which takes more time than adding an event to the queue. However, “more time” still isn’t much—this process takes about 1ms, far below the threshold of user visibility. 

3. There are instances where the queue can take longer to process, such as when there is a significant DOM mutation that must be compressed before upload. In these cases, the data capture script does far less work than the script that produced the mutation in the first place. These instances are almost always associated with major user actions like paging a table or list view, where a few extra milliseconds isn’t noticeable. We’ll talk more about compression in the next session. 

Upload bandwidth

Of course, the FullStory script doesn’t want to push more data upstream than is strictly necessary. FullStory’s script captures the entire document object model (DOM), which can be fairly large—though still smaller than the size of the downloaded HTML.

To mitigate this, the script compresses all HTML before it’s sent to the server using an algorithm specifically built to run efficiently in JavaScript. The script also doesn’t send external fetched images or CSS over the network, which often make up most of a page’s data. Instead, these are fetched later by FullStory servers to use in Session Replay. 

If you’re using a Digital Experience Intelligence solution that’s slowing down your site, you could be driving users away before they even have a chance to interact with your brand. 

It doesn’t have to be that way. FullStory’s DXI solution is designed to be lightweight—collecting the critical DX data you need to make smart decisions without slowing things down.