Many users leave these settings for what it is, but the freedom to make certain adjustments is there to keep our snippet as transparent as possible.

Web vitals version

Our pagespeed monitoring is built on top of Google's web-vitals library. Google is regularly updating this library. We are supporting several versions, where you get to pick which version of the web-vitals library you wan to run. This might be convenient for advanced users that:

  • want to keep using the same library version during important measurements and want to prevent skewed data due to difference in tracking characteristics;
  • want to test the impact of the web-vitals library itself on specific metrics (such as INP).

A changelog of the library with the characteristics per newly launched version can be found here.

Otherwise, you might want to enable "Latest" instead of "Manually picked".

Do note that:

  • new domains will automatically run on the latest stable version, unless you choose otherwise;
  • newer versions are more likely to be compatible with other preferences, such as metric debugging (which corresponds with the attribution build of the web-vitals library) and soft-navigations;
  • you do need to enable them individually though. When attribution and soft navigations were enabled but aren't compatible with the choosen web-vitals version, we will notify you within your domain's settings page.

Eval usage

When checking the inline snippet, you will see that the eval function is being used. The if-statement containing this function helps improving performance. This works as following:

Our tracking JavaScript needs to be loaded to know which pages needs to be tracked. The list of allowed pages (absolute urls as well as regular expressions) to track is then saved to localStorage, together with a function to determine if a newly visited page needs to be tracked.

This way, we can prevent our own full JavaScript from needing to be executed, which improved performance. In the end, pagespeed and performance is about the sum of optimization, and RUMvision likes to contribute to that in whatever possible form as well.

Removing eval

It is save to remove the whole if-statement block containing eval though. This just means that our JavaScript will then typically be executed on every page, even on pages where no RUM data will be collected. You could, however, change this within the inline snippet itself, or using GTM triggers to your own liking.

When to start tracking

RUMvision will load as soon as possible, but you can determine when it actually starts collecting data by changing the trigger in your snippet settings:


Metrics and custom timing will start to collect right away, as soon as our RUM JavaScript is executed as well.

On interactive

Although our RUM will be executed right away, it will only start to collect metrics (and custom timing) once the document.readyState has been or becomes interactive. We check this by adding an eventListener for readystatechange when document.readyState equals loading, and wait until it becomes interactive.

This can be convenient when you want to analyze conditions (such as URL matching via CSS selectors) while such element might not have been parsed by the browser yet.
Because when elements are not parsed, they won't be part of the DOM tree and a CSS selector will then not be a match yet when using "Directly". That's why we will automatically switch your script to "on interactive".

This may not work properly with elements that are client side rendered. Prevent creating CSS selector for such elements.

On Window Loaded

The Window Loaded (or load) event will happen after the interactive event. It can be convenient to use Window Loaded when you have reasons to believe our RUM would do a better job collecting information. For example when using user timing that is being added dynamically.

If our tracking script sees that the document.readyState equals complete already (for example it was delayed via GTM anyway), metric collection will start right away.

Otherwise, an event an eventListener for the load event will be added to only start collecting when the load event is fired.

Our script already is privacy friendly, but you can tailor it even more. If you want to adjust this dynamically, be sure to check the ones below and then read the documentation to change behaviour using JavaScript.

Read more about the privacy of our tracking mechanism over here.

Developer preferences

Allow yourselves more freedom with the technical options below.

Custom endpoint

In case beacons containing collected data should be transferred via your own server, you can fill in your own beacon endpoint. This would also move responsibility for data collection, binding and aggregation to your side as well.