Skip to main content

Does The RUM Snippet Impact Performance?

A performance monitoring tool shouldn't slow down the website it measures. This page explains how the DebugBear real user monitoring (RUM) snippet is built to keep its impact on your visitors low.

DebugBear is a dedicated performance monitoring tool. That means it has a lower impact compared to more comprehensive tools that provide comprehensive user journey tracking or intercept specific JavaScript function calls.

Loading the DebugBear RUM snippet​

The RUM script currently weighs around 20 KB compressed. It's served from cdn.debugbear.com, a global content delivery network, so visitors download it from a server close to them.

The embed code loads the script asynchronously. That means it does not block rendering of your page content.

It also means that the snippet request is low-priority. That's correct, because loading your actual page content is more important than loading analytics code.

Cache duration​

Currently, the script is cached for 4 hours by default. That means changes you make to your snippet settings may take up to 4 hours to take full effect.

If the cache duration was longer that would either mean that settings take longer to take effect or that you would need to update the embed code and script file name every time you make a setting change or we update our code.

CPU impact​

Measuring Core Web Vitals doesn't require much work from the snippet. The browser collects the data and then asynchronously reports it using Performance Observer callbacks.

We perform some synchronous work when the user clicks on a page. That's so that we can provide interaction element reporting for page elements that are removed from the page after the user clicks on them, for example a button to close a dialog. We keep the work that's done to handle these interactions minimal.