Performance as a feature: How to evaluate the speed and reliability of your digital experience platform

Before you can embark on a digital experience initiative, you have to start with a foundation of fast, reliable web performance.

You can streamline UX and conversion flows all day, but none of it matters if your site is painfully slow. Customers will bounce or give up based on speed alone.

Because perceived performance is critical to user experience, the last thing you need is a digital experience tool that weighs down your website or your app. That will only exacerbate the very problem you're trying to solve.

Any third-party service you want to use to optimize your digital experience, from A/B testing to analytics, is going to have some impact on the total load time of your page.

The key is setting a “performance budget”—an allowable tolerance of that impact—and ensuring the solutions you select fit within it. 

Your goal should be to reap the rewards of third-party platforms without "breaking the bank" or passing along the costs of poor performance to your customers.

Need to free up room in your performance budget? Start with the basics:

• Optimize image and media files

• Minify JavaScript

• Implement caching

• Serve content from a CDN

• Remove scripts from third parties no longer in use

What to look for in implementation

For most digital experience solutions, the first step is to install a library of code, typically with a bit of JavaScript. This library enables the service to continuously log digital interactions via Session Replay. 

Here's what to look for:

• Stability and uptime: Does your provider supply an SLA for uptime? Do they alert you proactively if analytics are interrupted?

• Client-side processing: Is the script that initiates the service a static script that indexes everything? Or, does it do the heavy lifting, such as event naming or currency conversion, client-side? Does the script increase in size as you want to report new events or metrics?

• Perceived performance: Does the script block page rendering? Does it interrupt interactivity with elements on the page?

Digital Experience Intelligence and performance

Fullstory’s Digital Experience Intelligence (DXI) solution is designed for speed and reliability from the ground up. 

From one single, tiny recording script (about 58.8 kB, gzipped), customers of Fullstory gain access to 100% complete, instrumentation-free analytics, high-fidelity session replay for every session.

Because Fullstory starts by capturing every digital interaction with the website or web app—with personal data either excluded or masked at the source in the browser or on the device—the size of the Fullstory recording script always stays small.

Your team can build new segments, dashboards, or analytics views in Fullstory without needing to further alter the script code. That means no manual instrumentation.

What does this mean for your business? 

Start small, stay small

When it comes to DXI, the script won't "balloon" over time as your team analyzes additional data for future business use cases.

Compare this to other digital experience platforms which require ongoing instrumentation or additions to their recording scripts. With other solutions, every new data point you'd like to analyze requires a manual update behind the scenes. This not only introduces the possibility of human error but increases the size of the file.

In many cases, customers of legacy digital experience tools are unaware of the real size of their script, and that they slowly creep up over time.

Minimize the fetch

Beyond simply being and staying small, Fullstory's recording script is edge-cached on Google’s Cloud CDN. Fullstory monitors and verifies the performance of the script with a third-party synthetic monitoring service that runs constant tests from more than 40 locations around the globe.

In our monitoring, we see that fully loaded times for the file are typically ~20 ms, with some variances depending on global regions. Conservatively, you should expect to see fully loaded times in the range of 50 ms to 150 ms.

Get out of the way

In addition to being small and loading quickly, the Fullstory script also loads asynchronously.

Here's how it works: a small stub script loads the main script (fs.js), but only after other required static resources such as CSS and images load first. This means that Fullstory will never visually block page rendering or interactivity.

Once loaded, the recording script is cached locally in the browser for 10 minutes. It won't load all over again as your visitors navigate from page to page. Every 10 minutes the browser will perform a one-time check to the CDN to look for the latest version. If a new version is available, the browser will download and cache the latest. 

While new updates only happen about once per week, any other requests would receive a response code “304 - Not modified” which takes less than 10 ms to complete.

And, because the script loads asynchronously, it's near impossible for the Fullstory script to impact the availability of your website or web app. 

On the off-chance that the Fullstory script ever becomes unavailable for any reason, it won't take your site or app down with it. Fullstory loads asynchronously and will never visually block page rendering or interactivity.

Optimize recording

After the initial recording script loads, Fullstory sits quietly in the background while your users interact with your website or web app. 

Without processing any complex logic or interfering with the page, it records every mutation in the DOM and bundles those changes in the memory on the browser. During periods of inactivity, the bundled events are compressed and flushed to Fullstory servers—about every 5 seconds or so.

These bundles of events are assembled and sent to Fullstory servers asynchronously to minimize execution on the main thread. Fullstory's bundling processes are never allowed to delay dynamic page rendering or affect the interactivity of any elements on the page.

Understanding performance impact

Verifying perceived performance

When it comes to measuring performance, the most important consideration is the perceived performance or impact on real visitors. For this reason, many web performance leaders have shifted focus from traditional page load times to metrics such as First Contentful Paint (FCP) or First Input Delay (FID).

In order to get a sense of perceived performance, we recommend you use a synthetic web performance monitoring solution, such as Splunk, Catchpoint, or New Relic Synthetics. 

With a synthetic solution, you can simulate page loads from multiple geographic locations, report on performance trends over time, and scrub out any outliers. This method will give you the most complete and comprehensive set of data to ensure your digital experience platform’s recording script will fit within your performance budget.

Alternatively, you may choose to use an open-source solution such as Sitespeed.io and create a custom dashboard to watch metrics over time.

Curious to see for yourself?

Contact us to request a tailored performance review of Fullstory’s Digital Experience Intelligence platform. We'll partner with your engineering team to deploy Fullstory in an environment where you can measure how we stack up.