Advanced

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".

Manually picked

Take control over the web-vitals version your site is using by manually picking the version in your snippet configuration.

You can stay in the loop about new versions by subscribing to our newsletter.

Latest stable

Your site will use a recent web-vitals version soon after Google published a new stable version.

Do note that there will be a delay between the official latest web-vitals version and our latest stable version. That's because we typically reserve time to test the latest version as well and wait for potential production issues to appear and resolve.

In general

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 these individually. 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

Our JavaScript snippet contains an eval function as part of a performance optimization strategy. While eval is generally discouraged in JavaScript, we've implemented it with specific safeguards for a particular performance use case. Let's explain why and how we use it.

How it works

Our smart initialization process works in two steps:

First, RUMvision stores your monitoring preferences in localStorage, including your URL rules and a specialized function that determines which pages to track. Then, on subsequent page loads, we use eval to quickly check if the current page needs monitoring, even before our full tracking JavaScript has been embedded.

This approach means we only load our full tracking agent when necessary, keeping your site fast and efficient. It's a small optimization that adds up to (in our case small) performance gains across your website as it prevents our JavaScript from even blocking the main thread when it's not actually needed on certain pages.

Security considerations

The eval function in our snippet only executes code that RUMvision has previously stored in localStorage. This code is:

  • Generated by RUMvision's systems, not from external sources
  • Limited to URL matching functionality
  • Cannot be modified by third-party scripts due to localStorage's same-origin policy

While eval can be a security concern when used with untrusted input, our implementation ensures that only RUMvision-generated code is executed, within the specific scope of URL matching.

Like any web-based technology, our implementation could theoretically be vulnerable to sophisticated man-in-the-middle attacks. This is a common consideration for all JavaScript running in web browsers, not unique to our use of eval.

When to remove eval

While our eval implementation is secure and optimized, we understand that some situations call for alternatives. You can safely remove the eval-containing code block in any of these scenarios:

  1. Full Site Monitoring:
    When monitoring Core Web Vitals across all pages, as no pre-check is needed
  2. Tag Manager Usage:
    When using Google Tag Manager or similar tools with page-specific triggers
  3. Security Policy Requirements:
    When your security policies prohibit eval usage

How to remove eval

There are two methods to remove the eval functionality:

  1. Via Configuration Interface (recommended to prevent other users from introducing eval usage in the future when copy and pasting the provided code):
    • Use the snippet configurator in your RUMvision dashboard
    • Disable the eval option
    • Copy the newly generated snippet
  2. Manual Removal:
    • Remove the entire if-statement block containing the eval
    • Keep the core tracking code

While most changes in tracking configuration will automatically be reflected in your snippet, the above change requires manually updating the snippet in either your website or tag manager after making either change.

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:

Directly

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.

Table of Contents