With Core Web Vitals, real user experience data became popular. And everyone and their dogs started to become acquainted with pagespeed and so-called field data. As field data is based on real user experiences out in the field, it is just another word for Real User Monitoring (RUM).
Core Web Vitals versus instant data
Google published an API to fetch this RUM data, for free. But there are important nuances:
- It is delayed
- It is Google Chrome only (and yes, Google Chrome on iOS is excluded, unfortunately);
- It costs a lot of time to set it up properly;
- You'll need a fair amount of knowledge.
This especially is something to consider when using solutions with a wide variety of features. Most SEO or uptime monitoring toolings started to also embed Core Web Vitals, but often with the above restrictions.
Missing metrics
We already noticed that clients started using RUMvision as other solutions didnât embrace the Core Web Vitals metrics just yet, or were slow to adopt new metrics such as INP.
Limited debugging information
Whenever using PageSpeed Insights, you get to see the 3 Core Web Vitals metrics plus 3 additional metrics. PageSpeed Insights is calling the additional metrics âother notable metricsâ. But when you want to deep-dive and debug, you need way more information than just a set of metrics. For example:
- Are issues only happening under specific conditions;
- And what are the nuances per -for example- TTFB and LCP?
When talking about conditions, we are talking about device conditions, internet connectivity conditions, page conditions, and caching conditions:
- Are performance issues caused by device memory?
- Are TTFB issues the result of caching strategy differences, query strings, or just specific pages or CDN?
- And is it caused by increased DNS look time, connection time
- And does the LCP depend on the internet speed, lazyloading or did you forget to add the fetch priority attribute?
Not all Real User Monitoring solutions will track these nuances, lacking the possibility to alert you.
Privacy compliant
Privacy compliance has two cases here:
- With a European audience, you should comply with the GDPR
- And data should be stored within the European Union as well.
GDPR
GDPR is the European privacy law. As part of the GDPR, one isnât allowed to store all types of user information. Any personally identifiable information (PII) canât be stored without user consent. The boundaries are sometimes quite thin here, so thatâs why we are privacy compliant by default. From there on, you can configure your snippet to decide what to track. Or actually, start tracking information after youâve asked for consent via a cookie notice.
And by the way: we never actively send IP addresses and user agent strings to our servers. Any browser analysis will be done client side so that we donât need to actively receive or store this kind of information.
European data storage
Data is not allowed to be shared with others. This means that choosing a RUM solution that is storing data outside of Europe or could be accessed by parties outside of Europe automatically means that it doesnât comply with GDPR.
Tell us what to track
Most RUM solutions will track everything. But when you think about it, that isnât necessary. In the end, many pages will be the same when it comes to technical and UX characteristics. We arenât saying you should only track one URL per page type, as you are then likely to miss nuances.
Nevertheless, when using RUMvision, we made it very easy for you to decide which pages to track. You can use regular expressions to track all product pages when the availability of products and thus product pages are changing regularly. Moreover, you can:
- Set up a sampling rate when specific regular expressions or URLs are receiving too many requests;
- And actively exclude pages, such as checkout or account-related pages.
Load what you choose
We like this one the most, as no other Real User Monitoring solution out there is doing what we do when it comes to limiting the impact on performance.
Sure, some other solutions might allow you to track specific URLs only. But we went the extra mile with this one.
We will only bundle and then load the JavaScript based on your needs.
Letâs be honest: in the end, any Real User Monitoring solution will involve JavaScript. A RUM solution will tell you about performance issues, but shouldnât become on themselves.
Whenever choosing your tracking options in the snippet configurator, we will show you the impact on the (uncompressed) snippet file size! Quite convenient and transparent!
Impact of snippets by third parties
We donât impact performance
The sooner our snippet is loaded, the more data it will track and thus the more accurate the data will become. This isnât different from any other tracking solution, such as heatmaps or analytics. The advantage of RUM solutions over analytics is that RUM is working with percentiles, so missing a few data points might not impact 75th or 80th-percentile outcomes that much.
So, although we like to believe that real UX and Real User Monitoring deserve priority to boost conversion, our snippet doesnât need the highest priority.
We wonât load on all pages
Yes, we said this already. But most third parties saying this means: we wonât collect data on all pages, but the JavaScript is still loaded and executed. For example, the typical cookie-consent implementation will continue to impact your performance on every other page hit. Even if the visitor already accepted cookies. Sure, the triggers need to be submitted to your (Adobe or Google) Tag Manager, but thatâs everything a cookie notice needs to do from that moment.
Thatâs where we decided to come up with a neat trick: all URLs or Regular Expressions are saved in your browser during that session. When navigating to another page, the URL will first be checked against your URLs and Regular Expressions. If there isnât a match, our JavaScript wonât even be executed.
You can easily check this by opening DevTools, navigating to the network panel, and filtering on a âRUM-â file loaded from CloudFront. You will see that it will be executed on your homepage, but likely not on your sitemap or privacy page (depending on your configured URL rules).
Snippet dev-mode
We didnât just create an idle snippet. You can actively communicate with our snippet. But only when you opted into this in the snippet configuration.
For example, maybe you told us to track country or device information in the snippet configuration. If you did, it would be a shame if youâre using yet another third party to fetch such information and provide users with tailored notices, such as alerting them to visit the USA shop when theyâre from the USA but reached the UK domain.
And the same applies to core Web Vitals as well. If another third party is tracking this as well, then we donât need the library. You could then disable our library in the configuration settings, and be sure to report every metric to us manually.
You can all do this by calling specific functions. Such as rumv(âgetâ, âbrowser_brand) or rumv(âgetâ, âbrowser_versionâ). This way, you could even warn people when they are on older browsers, or choose to load polyfills on certain occasions.



